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

On Fri, 2 Apr 2004, Orion Adrian wrote:

> >So you mean you would accept <nobr> in the <code> disguise? Then I think
> >you haven't understood the problem.
>
> I think I understand the problem and I think he's right. I think though
> there is a semantic difference between code (e.g. C, C++, HTML, Java) and a
> code (e.g. %20, $abc).  One should allow normal breaking rules and one
> shouldn't.

So you are saying that <code> markup is logically independent (or
"orthogonal to") line break prevention. That's what I've been saying. What
is or is not "computer code" is largely irrelevant here.

> 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. And it surely
does not imply any specific line breaking rules.

> Markup like sub, sup, hr,
> nobr are presentation classes because going along and making up semantic
> cases for all the nitty gritty little cases is too big a task for this
> working group.

Well, sub and sup have always have dual definitions - partly just
stylistic formatting (M<sup>lle</sup>), partly structurally most essential
(10<sup>6</sup> is not just a stylistic variant of 106). And so has, in
fact, hr; by name, it's horizonal rule, but by logical reference, it's
change of topic. The nobr markup would be much better defined, in fact.

> So my point is that if you desire total purity look to these
> other cases as well.

I haven't asked for total purity; au contraire.

> Concentrating all our effort on nobr without looking at
> the whole problem is just wasting everybody's time in my opinion. There is a
> much bigger problem at hand here, let's not concentrate on the minutia.

What bigger problem? 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) 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.)

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Friday, 2 April 2004 17:47:58 UTC