Re: <NOBR> - Returning to the question....


On Sat, Apr 03, 2004 at 01:47:56AM +0300, Jukka K. Korpela wrote:

> > This is an English problem mostly in that one person sees code
> > meaning one thing and another sees code meaning something else. This
> > is one area the W3C could do much better in (i.e. defining the exact
> > meaning of each semantic markup).
> Agreed, but "Designates a fragment of computer code" is actually more
> specific than most of the definitions for text level markup.

Yes -- much too specific to be useful. That's why I have proposed a
different definition.

> And it surely does not imply any specific line breaking rules.

I'm still in search of any example for either:
- A situation where something inside <code> (even in my broad defnition)
  is definitely desirable to have normal line breaking rules appiled, or
- A situation where something outside <code> (i.e. natural language)
  definitely shouldn't have normal line breaking rules applied

(Definitely here means: It's important that it works even in a browser
not understanding possible style sheet overrides, for it would destroy
the meaning.)

> Do you mean the question whether the minor changes to XHTML 1 made in
> the current XHTML 2 draft really justify breaking the long tradition?
> There's remarkably little new in XHTML 2, yet it has been designed to
> fail on existing browsers. If you ask me, it's time to state that if
> _this_ is what it's going to be, it should be defined as XHTML 1.2 (or
> actually HTML 4.1, but I don't think there's a way back from the XML
> path)

No there isn't, and that's a Good Thing (TM). While SGML in theory is
much easier to edit by hand (in the case of HTML only in theory, as no
major browser supports any of the nicer SGML features), the considerably
lower cost of processing XML opens applications not feasible with SGML.

> and cleared up so that existing browsers will display it just fine and
> future browsers a little better. Just drop <h> and <l> and <nl>
> (mostly great ideas, but too late) and define something that can be
> used here and now, and implemented in full later. Accepting <nobr>
> would fit well into this pragmatic approach. (And in the HTML/CSS
> tradition, we might well skip XHTML 2.0 and call the next version XHML
> 2.5 even though it's just an update to HTML 4 oops I means XHTML 1.0.)

What you are actually asking for is HTML 3.3: A presentational language
that codifies the (mis-)features of existing browsers.

Sorry, that's not what XHTML 2 is intended to be. You are asking for a
full turn here, where the overall direction to go has been decided (and
justified) nearly 10 years ago.


Received on Saturday, 3 April 2004 10:01:02 UTC