- From: Ben Boyle <benjamins.boyle@gmail.com>
- Date: Sat, 29 Dec 2007 22:19:30 +1000
- To: "Maciej Stachowiak" <mjs@apple.com>
- Cc: "Ben 'Cerbera' Millard" <cerbera@projectcerbera.com>, "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, "Simon Pieters" <simonp@opera.com>, HTMLWG <public-html@w3.org>
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