W3C home > Mailing lists > Public > www-html@w3.org > April 2004

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

From: <olafBuddenhagen@web.de>
Date: Sat, 3 Apr 2004 14:19:05 +0200
To: www-html@w3.org
Message-ID: <20040403121905.GB527@sky.local>


On Fri, Apr 02, 2004 at 05:19:34PM -0500, Orion Adrian wrote:

> I think though there is a semantic difference between code (e.g. C,
> C++, HTML, Java) and a code (e.g. %20, $abc).

Sure -- as you have observed below, semantics is always a continuum.

However, the differences between various kind of code are very small
comparable to the difference between code (in the broad sense I use) and
natural language.

The distinction between natural language and computer strings (whether
code in the classical meaning, or other kinds of symbolic data) is
important (the line breaking being only one of relevant differences),
while the subtle differences between unnumerable kinds of code are
really neglectable and ouf of the scope of a generic language like

> One should allow normal breaking rules and one shouldn't.

Sorry, I hope I misunderstand this statement. You do not really want to
apply normal line breaking rules to programming languages, do you?...

> 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).

Exactly. That's why I proposed a (useful) definition for <code>.

> Here's the greater problem... there are so many semantic cases in the
> real world that anyone trying to accomplish a general-purpose semantic
> markup is going to have to choose along a continuum of choices.  On
> one end you have giving up entirely and just encoding presentation and
> on the other end you have semantic markup for everything.

Yes. But between those extremes, there is no straight line of possible
compromises. Instead, there is a variety of possibilities of very
unequal qualities. Some are really bad compromises, which do not really
help either goal. Others are quite good in allowing useful semantical
markup in many cases, while at the same time not getting too specific.
<code> with the broad meaning I suggested, definitely belongs to the
second group.

> I've found that the HTML Working Group so far has decided to go
> somewhere in the middle. 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.

Actually, both <sub>/<sup> and <hr> are very controversial cases, where
no real consensus has been achieved yet. Maybe it's time to return to
these... At least for <hr>, I have found some very strong conclusions.

> So my point is that if you desire total purity look to these other
> cases as well. 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.

The task of designing a really good semantical language is too
complicated for a top-down approach. It's simply too complex, the
implications are far too many for anyone to come up with useful ideas
this way.

Observing past discussions, one can see that often discussions started
on some minutia, have opend up much more fundamental issues.

See how the discussion on the <nobr> element has evolved: Starting from
that point, I've developed a useful definiton for <code>, and by the way
solved the Programming Collection dilemma. (At least I believe so...)

Another example was how the discussion on some specific element (I don't
remember which) led to fundamental questioning of the block/inline
distinction. (I'll restart the debate as soon as I have catched up with
my mail...)

While the first drafts of XHTML 2 mostly concentrate on details, and
over all look quite similar to older HTML versions, some discussions
(especially during the past few months) indicate that the final version
might be very much different. With fundamental changes, that came up in
discussing minutia.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:08 UTC