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

Hi Smylers,

On Jul 19, 2007, at 9:21 AM, Smylers wrote:

>
> Robert Burns writes:
>
>> Consider deprecating <strong>.
>>
>> With nested<em>, and CSS (including media rules) <strong> is no
>> longer a very useful element.
>
> I agree that it doesn't seem to have much utility, being semantically
> hard to distinguish from <em>.  In most situations a single form of
> emphasis is sufficient[*0] (or indeed, for those that have a style
> guide, mandated).  There are several plausible ways of choosing to
> render emphasized text (italicized, emboldened, capitalized,  
> coloured),
> but with CSS any of these can be applied to <em>, so a distinct  
> element
> is not needed for each.
>
> However ... <strong> exists; browsers will continue to support it.  Is
> allowing authors to continue to use it actually doing any harm?

No, I agree 100%. There's not really any harm done by keeping it in  
document conformance. Normally, I wouldn't  even suggest removing it  
from document conformance (obviously it will stay in our UA  
conformance criteria regardless). My concern, is that I think it  
should just be left alone. If there is a pressing need for an  
<important> element, then add an <important> element. However, don't  
call that element "strong" because that causes a name collision and  
it messes with our compatibility with XHTML1 and XHTML1.1. If the use- 
case / problem is: authors need a way  to express important phrases,  
then it makes sense ot me to just add a new element to express  
important phrases. However, we shouldn't name that element "strong"  
because that causes a name collision.

>> Changing its meaning (or adding a new <strong> element with a
>> different meaning), as currently proposed by the draft causes a
>> namespace collision. Particularly without versioning, it would be
>> impossible to tell whether a document meant <strrong> as in strong
>> emphasis or <strong> as in important.
>
> I'm not convinced that HTML5 is changing its meaning: I'd've thought
> people emphasize things because they are important.

Authors emphasize words or phrases because it changes the meaning of  
a sentence. If that's how you're using "important", then yes.  
However, there's a long tradition calling that "emphasis" so why are  
we trying to get authors to call that "important" instead.. The  
current draft has some very nice examples of emphasis that changes  
the meaning of a sentence.

In addition, authors emphasize words to draw attention to them in a  
quotation. In that sense, they may be said to be important: i.e.,  
important for showing how the quotation supports the surrounding  
prose. However those meanings have typically both been called  
"emphasis". Moreover, the use of "important" in emphasizing words in  
some other author's quotation is not the same meaning of important  
used in the draft (as far as I can tell), which is more like drawing  
attention to words and phrases for those skimming a document for  
important parts. In any event, it would make more sense as I've  
already said to differentiate that newly proposed semantic from <em>  
by adding an <important> element. After all, authors are using <em>  
in both cases (changing meaning and highlighting the important words  
in a quotation) so those use-cases do not involve <strong> at all.

> Please can you give examples demonstrating the distinction as you see
> it, that is:
>
> * current webpages where <strong> is correctly used to emphasize
>   something, but that that thing isn't important (and as such would be
>   misinterpreted by HTML5 browsers)

First, in response I want to say that the interpretation by HTML5  
browsers (or any browser) should not be that much of a concern with  
this and  similar elements. There are a whole lot of elements that do  
not really get a lot of "interpretation" by a browser. For most  
elements, the browser is mostly a CSS engine that happens to have a  
particular default CSs stylesheet. The point is to be able to use  
these semantics for other UAs such as semantic extraction, search  
indexing or simply for posterity in encoding an authors intent. In  
other words, these semantic constructs give authors a means of  
expression. That means of expression is there whether a browser's  
default stylesheet recognizes it or not.

{Aside: To me, CSS has proven itself reliable and ubiquitous enough  
that the issue of a browser's default stylesheet should not even be  
that big of a concern for us. The only other semantics we need a  
browser to interpret (not covered by CSS) for compatibility is to  
treat <title> as a title, to treat <script> as containing a script  
for execution; and to properly associate stylesheets from <link> and  
<style> elements. Basically everything else is just CSS processing of  
the document. So HTML asks very little of an HTML browser (that CSS  
doesn't already expect I mean).}

Anyway, maintaining separate elements for "emphasis", "strong  
emphasis", and "importance" provides many means of expression with  
very subtle differences: emphasis on "very subtle". I'm not  
necessarily opposed to that, however it seems counter-intuitive to me  
that we would have three different elements for these subtle phrasing  
differences (and nested phrases too) and then be focussing on an 80%  
use-case rule in other areas of the draft. Certainly authors have a  
greater need for providing accessibility-oriented semantics in their  
documents than providing a distinction between a word that is  
emphasized, one that is strongly emphasized and one that is offset  
from the others due to its importance. I would think offering nested  
<em> elements would be sufficient for quite a range of expressibility  
without also maintaining a <strong> element and an <important>  
element in our document conformance criteria (to me <strong> would  
simply be like 2 or 3 or n nested <em> elements anyway).

<strong> is often used to emphasize words in the same way as <em>. in  
other words not for importance, but to shape the meaning of a  
sentence. I think in many ways <strong> is used (or even <b> rather  
than <i>) because bold is more easily distinguishable in low- 
resolution output (like current displays). That may even be the very  
reason that <strong> and <b> existed in the first place. Italics just  
doesn't stand out as well on screen as it does in print. In those  
cases, <strong. is not being used in the same way as the draft  
describes <important>  (unless important simply means emphasized).  
Again these are all subtle differences, but I think there big enough  
differences that we cannot simply introduce this new meaning and use  
the same XHTML1 namespace name.

> * theoretical HTML5 mark-up where <strong> is correctly used to denote
>   something as important but that it would be wrong to emphasize it  
> (and
>   as such would be misinterpreted by legacy web browsers)

I think the example in the draft is a good example of a use of  
"important" that does not really correspond to "emphasis" (strong or  
otherwise).

<p><strong>Warning.</strong> This dungeon is dangerous.
<strong>Avoid the ducks.</strong> Take any gold you find.
<strong><strong>Do not take any of the diamonds</strong>,
they are explosive and <strong>will destroy anything within
ten meters.</strong></strong> You have been warned.</p>

Imagine changing those elements to <em> and I don't think they work  
as emphasis  (and not because it needs to be emphasized more  
strongly). It is more like an instruction manual that's trying to  
draw your attention to certain words or phrases so that you may skim  
it quickly and get the gist of it. I don't think that's how <strong>,  
as in "strong emphasis" (or <em><em></em></em>) should be used.

Just to summarize, I'm fine with leaving <strong> alone (as in  
leaving the same definition for <strong> as that in HTML4 and XHTML1.  
It is the messing with <strong> that I find troublesome. If there's  
an apparent need for an <important> element then I support adding one  
(so long as it doesn't have a name collision with existing elements  
in whatever namespace we go with).

Take care,
Rob

Received on Thursday, 19 July 2007 23:37:28 UTC