Re: Underline element.

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