- From: Leif Halvard Silli <lhs@malform.no>
- Date: Sat, 29 Dec 2007 19:10:10 +0100
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- CC: HTMLWG <public-html@w3.org>
Patrick H. Lauke 28.12.2007 21:35: > Ben 'Cerbera' Millard wrote: >> An alternative is <span class>. The smallest possible example of that: >> >> [[[ >> <span class="u">foo</span> >> ]]] >> >> This uses 23 bytes of markup. <font class> would be identical. The >> <u> version would use 70% less markup each time. > > Is the goal semantic clarity or brevity here? 'brevity' and 'semantic clarity' are often the same thing - at least from an author point of view. And authors are often the ones we have in mind when we e.g. speak against the use of the FONT element. Because, for whom is a document to be semantic? The author? The user? Or the user-agent? For authors, brevity makes the code simpler to read - more semantic. More semantic, because it becomes simpler to consentrate on the semantics. However, for users, the code can be very messy, without having any effect on the semantics. The same is the case for user agensts. Presentatinonal HTML elements do not need to result in presentational mark-up. Presentational mark-up is when presentational HTML elements are used as a replacement for semantic HTML elements. We should separate the subject of 'presentational HTML elements' from the subject of 'presentational mark-up'. (I guess we ought to separate semantic attributes from presentational attributes, as well.) If I want a header element with underlined text, then <h1><u>subject</u></h1> does not add any semantic mess. It adds code mess, but not semantic mess. However, if I use <h1>the <u>main</u> subject</h1>, then I might add semantic mess, at least if I use <U> when I really should have used <EM>. On the other side, to use <h1><em>subject</em></h1> is also messy and - possibly - also semantically messy (I guess it could create problems for screen reader UAs). The argument against presentational mark-up is _also_ that it creates - or is an example of - messy mark-up. For instance, to use the FONT element each time there is a change in the use of typeface, leads to messy mark-up. However, if the FONT element does not interfer with the use of semantic HTML elements, then I cannot see that the FONT element interferes with semantics. Except, of course, for the author. For him or her the use of FONT usually makes - or made - the coding job a burden. Presentational elements makes it possible to make presentatinal mark-up, i.e. something that looks good, but which, when the reader wants to catch the structure of the document - or when the non-sighted user wants to read it - doesn't reveal what is header or emphasized text - etc. But then, if we follow this argument to the the end, then CSS in itself is a danger. Because CSS allows us to e.g. style SPAN and DIV to give a visual impression of the semantical structure. (And I guess, when UA starts to support it and CSS is enough developed, then one could even use aural CSS to make sense out of nonsensical, presentational, markup. In conclusion, I don't think that I am in favour of removing* U from HTML, but rather would I like to see that its usecases is specified better. However, I would like to propose a new thing, namely that I, B and U should be viewed as *distinct* variants/equivalents of the SPAN element. Because, currently HTML5 says about the SPAN element that it: "doesn't mean anything on its own, but can be useful when used together with other attributes, e.g. class, lang, or dir, or when used in conjunction with the dfn element". And take for instance how SPAN can be used with the DFN element. THe secton about the DFN element says: "The DFN element enables automatic cross-references. Specifically, any SPAN, ABBR, CODE, VAR, SAMP, or I element that has a non-empty title attribute whose value exactly equals the term of a DFN element in the same document, or which has no title attribute but whose textContent exactly equals the term of a DFN element [...]" For some reason, that paragraph doesn't mention the B element as one element that can be used for automatic cross-referencing, this way, despite that it is said about the B element (in the section about the B element) that it can be used for 'key words'. This must be an error! I propose that both U and B get a mention which says that it can be used this way. A usecase for the U element that hasn't been mentioned ,can be linked to the above mentioned use of the DFN element: If one wants to use DFN in combination with SPAN, U, B, I etc., then authors could e.g. use the I element for one kind of key words, the B element for another group of keywords, the U element for a third group - and so on. Quite more handy than having to use e.g. SPAN with different classes all the time. And I would argue: More semantic for the authors. But also, as long as the HTML5 draft says that the I element should be differentiated - in voice - from the surrounding text, then should/could also the B element and the U element. And thus one could that way get some useful semantics for users of all kinds. *removing: I said 'removing' because that is how I see it, despite the claims about creating HTML5 from scratch. I support the view that with HTML5 we try to look at HTML with fresh eyes. -- leif halvard silli
Received on Saturday, 29 December 2007 18:14:34 UTC