Re: Underline element.

On Dec 29, 2007 9:08 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Personally I think <u> should remain conforming, if only to give HTML
> editing UIs something obvious to insert when the the [U] button is
> pressed. At the same time, I agree that underlining non-hyperlink text
> in an HTML document is usually a poor practice.

I agree, and add that poor practice doesn't mean there aren't valid
uses (some of which have been given throughout this thread). I'm not
so sure about the U buttons in authoring tools, but we should leave
that for ATAG to sort out if needed.

To address the point about poor semantics of U, B and I elements. I
agree underline, bold and italics are not very meaningful in the
semantic sense. They are "presentational". But I have always thought,
and still think, that HTML is all about presentation -- the
presentation of documents. I agree with the separation of structure
(html) and style (css), but I do not believe "presentation" and
"style" mean the same thing. I think presentation = structure + style.
Please note I am using "presentation" in a media-independent fashion
(and not specifically visual media). You may then note that b, i and u
are more "style" than "structure"... but I am not certain of this
distinction.

When there is a good case for better semantics, like citations, it is
great to have markup tailored to those that: the cite element. It is
better to use these rich elements over their generic counterparts
(e.g. the i element for italics, even given citations are often
italicised). And it is good to have the strong and em elements, for
generic "importance".

There are a lot of specialised types of documents though. We've had
poetry and code mentioned a few times in the past. Should we define
the semantics for all types of documents? No, we should not. There are
too many of them and not enough of us. Not enough experts in each
domain. For example, to do poetry justice, we would need experts in
the semantics of a poem. It's questionable how useful that would be to
the HTML community at large ... after all, there are hooks for
extending HTML (class attribute, namespaces for XHTML) which can be
used for added semantics. Look at microformats.

HTML is, by necessity, a subset. At its best, it represents the common
structural elements of a document: headings, sections, lists, tables,
citations; links, metadata and media elements. I'd like to see more
generic document constructs, like footnotes, supported.

To me: bold, italics and underline are document constructs. They
aren't rich in semantics. I agree with the point that it can't be
determined what italics "means". But it might make sense to a human,
who understands the type of document, and the context of italics in
that type of document. Yes, you could use "em" but emphasis is not
italics, and may not be rendered as italics in all conforming UAs (I'm
ignoring CSS btw).

So I'm all for leaving these elements in as conforming: even U. I'll
probably rarely use them. There are other channels where we can
promote best practice, although notes included in the spec would not
go astray. I think the editors have done well with i and b, explaining
what to use them for and encouraging appropriate use of strong and
headings (in the case of the b element). Read 'em:
http://dev.w3.org/html5/spec/Overview.html#the-i
http://dev.w3.org/html5/spec/Overview.html#the-b

Ah, one last point. It's worth noting how beautifully backwards
compatible these elements are. Let's say I decided to show file sizes
for links on a web page, and wanted them to be small and italics. I
can use span with a class to style this, but how is that going to
render in lynx? Why not nest the small and i elements, and assign the
class to one of those? Just a thought.

cheers
Ben

Received on Saturday, 29 December 2007 12:19:39 UTC