Re: part of my review of 3.12 Phrase elements (importance <strong> element)

On Jul 20, 2007, at 3:45 AM, Simon Pieters wrote:

>
> On Fri, 20 Jul 2007 08:52:15 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>
>>
>> The WYSIWYG (I'm supposed to have it reviewed already, but I  
>> haven't got there yet) section has a similar issue that you raise.  
>> Right now the draft says:
>>
>> "Even WYSIWYG editors, however, should make every effort to use  
>> appropriate semantic markup and avoid the use of media-specific  
>> presentational markup."
>>
>> This is dangerous advice without further qualification. That is if  
>> a WYSIWYG editor exposes controls to set text as bold, it should  
>> not under any circumstances be using <strong> instead. (a common  
>> mistake among WYSIWYG editors)  It is not semantic if the author  
>> meant bold and the tool inserts "strong".
>
> I think this is a lost cause. I also used to think that WYSIWYG  
> editors should emit <b> instead of <strong> when the user indicates  
> bold, and have tried to convince WYSIWYG editor vendors to change  
> their behavior without success. I have since then realised that the  
> benefit of trying to make a distinction between <b> and <strong> is  
> marginal and the cost of changing the world to conform is high. <b>  
> and <strong> are used interchangably in the wild, both because some  
> WYSIWYG editors emit <b> and others emit <strong> for the same UI,  
> and because many authors think <strong> is the new <b>. In  
> practice, they are thus synonyms.
>
>    http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/ 
> 009060.html

Well, I would say another contributing factor to why <strong> is the  
new bold is due to it not having a clear semantic in the first place  
(as I said the problem of italics as an indication of emphasis on low- 
resolution output is relevant here). I would say that <strong. is  
different from all of the other semantic elements (at least prior to  
HTML5) in not have a clear semantic use-case (rather just to provide  
a semantic receptacle for "bold").

>> I think the draft does too much of what you're saying. This  
>> doesn't relate to strong, but the remaining presentational  
>> elements, but I think we should simply be clear that <b>, <i>,  
>> <small>, <sup> and <sub> are presentational elements. Don't try to  
>> hide that fact: that's simply what they are. It's a counter- 
>> productive hyper-correction to try to refine/redefine them into  
>> semantic elements so that we can say we're fully semantic. [...]
>
> Saying that an element is "presentational" gives semanticists the  
> feeling that such elements must never be used.

YOu happen to be talking to a semanticist! :-) But seriously, I think  
you're over simplifying semanticists. I think there are reasons that  
we still have presentational elements for bold and italics and  
subscript and superscript (I think the case for <small> is a bit of a  
stretch). It is that there are many different semantics expressed by  
these that we probably cannot capture in semantic markup. For example  
we would need a FrenchAbbreviationML just to markup French  
abbreviations. At some point before then, I think you have to say:  
we've got enough semantic elements in HTML let's just leave a few  
presentational elements in there for these kinds of cases (no offense  
intended to the  French).

So I don't  think you're going to fool us semanticists by telling us  
<b> is a non-presentational element because its meant to be used for  
meaning that's presented in bold: that's just another way of saying  
this is a presentational element for presenting "bold" text.

> I don't think using the above mentioned elements when there is no  
> other "semantic" element in HTML available is harmful.

Agreed.

> I also think it's appropriate for WYSIWYG editors to emit these  
> elements instead of fiddling around with <span>+CSS.

Agreed for those only, except I would remove <small> since I do not  
think it fits the same criteria as the others. Having <small> to me  
is like having <green>. There just are not enough solid presenational  
idioms that use small or green text that it justifies us including  
that in document conformance.

> Using these elements has the advantage that non-CSS UAs get the  
> right typography (bold, italics, small print, superscript and  
> subscript often indicate something according to typographic  
> conventions) so that users can understand the intended meaning from  
> context (just like in print).

Understood. However, a conscientious author can add a meaningful  
class name to a span that conveys much clearer and less ambigouous  
meaning than a typographic convention could.

> Using these elements  [i.e., span markup with CSS?]  for  
> presentational *purposes* is harmful because it takes away the  
> opportunity for non-visual UAs and ATs to indicate the attached  
> typography change to the user. For example, in speech media, a UA  
> might want to indicate that something is superscript, so that the  
> user can work out what it represents. "2<sup>8</sup>" is different  
> from "2<span>8</span>".

Again, not if meaningful class names are used too (provided the user  
can turn to those as a fallback).  Being able to match a class name  
to a presentational convention would be very useful for visual, aural  
or tactile browsers since it covers the presentational cases when  
common conventions do not exist. For example: "I will use green text  
to indicate DOM attributes" is expressed through CSS as ".DOM- 
attribute {color: green}". Since there are no solid cultural  
conventions for presenting DOM attributes (at least not that I'm  
aware of)., the exposing meaningful class names is much less  
ambiguous. The same would go for using a <span> for a subscript  
presentation in the example I created:

<p>Mix liberally with H<span class='molecule-count'>2</span>O</p>

Granted, the presentation might get separated from the document and  
lose the subscript. However, the meaning is still unambiguous from  
the class name. It would not be (except through heuristics and the  
fact that this is such a common example) with H<sub>2</sub>O.

Notice too that the class name does not even need to be a part of a  
microformat or involved in any other authoring community. I can  
simply drop that class name in place and it makes the meaning much  
clearer than it could be with presentation alone (though it is more  
verbose than <sub>).

Take care,
Rob

Received on Friday, 20 July 2007 09:26:29 UTC