2012-01-24 1:18, Ian Hickson wrote:
<u>, for instance, was only added after rather
compelling use cases were presented.
The only use cases mentioned in the current version of "the living
standard" are "labeling the text as being a proper name in Chinese text
(a Chinese proper name mark)" and "labeling the text as being misspelt".
These are semantically so remote that using the same element for them is
artificial, to put it mildly.
What are the actual benefits of using <u> instead of <span>? The only
difference is that with <u>, the default rendering on common browsers
will use underlining. This is the true meaning of <u>, and abstract,
vague "semantics" will not help authors but confuse them.
What is _compelling_ about markup for proper names in Chinese? HTML has
had no markup for proper names in any language. Why introduce markup for
them in one language, with the assumption that a specific rendering
convention, now apparently rare, will be used?
What is _compelling_ about markup for misspellings? How many web pages
use such markup and need it, and why is it compelling that <u> be
available to them?
What is so _semantic_ about it if can mean Chinese proper name _or_
misspelled word?
By reusing existing elements, we are able to support them without
having to wait for new elements to be implemented.
Several new elements have been added without such concerns.
Again, you are incorrect. The concerns were very much present.
There was, for example, no support to <mark>. Maybe there is now, but I
doubt. Why wasn't an existing element, like <font>, wasn't used for it?
Or why don't the use cases for <mark> fall under those for <b>, <i>, or <u>?
Which "support" was needed? Right, underlining. So what's so difficult
in saying that <u> is just as semantic as <span>, except that <u> is by
default underlined?
With <u>,
many of the actual uses of the element can be seen as uses of both the old
presentational meaning and the new media-independent meaning without
conflict.
That's because "the new media-independent meaning" has been formulated
so vaguely that it can be ignored and the presentational meaning
understood as the real one. But people who will try to take the text for
real will get hopelessly confused (until someone comes to the rescue
saying "oh, <u> _really_ means underline").
I would no more think we need an element for "bolder" than I would think
we need an element for "louder" in speech synthesis or an element for
"bigger hand gestures" in sign-language interpretation (not that I'm aware
of a sign-language HTML UA, but there's no fundamental reason one couldn't
exist in the future). When you start from the fundamental position that
these media are no more important than each other, it is really hard to
see why we would ever introduce "phrase-level typographic features".
It's not that hard if you think that HTML is all about markup for
written languages. What speech synthesizers or Braille renderers do is
that the convert written text to other forms, often with serious
problems and limitations, and they have to deal with things like
bolding, underlining, and italics when they exist in texts being
processed. It does not help them the least to say that <u> in HTML
"represents a span of text with an unarticulated, though explicitly
rendered, non-textual annotation". They have their own ways of dealing
with underline, either by ignoring it or by mapping it something that
they can do.
Yucca
