[whatwg] contenteditable, <em> and <strong>

[Benjamin Hawkes-Lewis]

Henri Sivonen wrote:

> My conclusion is that semantic markup has failed in this case.

Semantic markup hasn't barely been tested in this case. For the most
part, users have been force-fed broken markup by deceptive user
interfaces. And, for the most part, developers haven't cared much about
semantic markup full stop.

An actual test would have been to provide people with a widespread
interface that accurately reported that they were emphasizing rather
than italicizing.

> <strong> and <b> are both primarily used to achieve  
> bold rendering on the visual media. Regardless of which tags authors  
> type or which tags their editor shortcuts produce, authors tend to  
> think in terms of encoding italicizing and bolding instead of  
> knowingly articulating their profound motivation for using italics or  
> bold. 

Yes, it's a bad habit picked up from WYSIWIG word processing. If people
were still habituated to typewriters you'd be insisting on the intrinsic
utility of <u>. ;)

> Even those who have heard about the theoretical reasons for  
> using <em> and <strong> 

[snip]

> <em>, <strong>, <i> and <b> have all been in HTML for over a decade.  
> I think that’s long enough to see what happens in the wild. I think it
> is time to give up and admit that there are two pairs of visually- 
> oriented synonyms instead of putting more time, effort, money, blog  
> posts, spec examples and discussion threads into educating people
> about subtle differences in the hope that important benefits will be  
> realized once people use these elements the “right” way.

If we accepted that only a few people have heard about the theoretical
advantages of em and strong, wouldn't that suggest that the web
standards community has not done enough communicating, not that
communication has been understood but ineffective because its
prescriptions are somehow impractical?
	
But in any case blog posts, spec examples, and discussion threads are
(largely) a waste of time compared to fixing tools like WYMEditor to use
a more accurate user interface, and even that's a waste of time compared
to fixing the big WYSIWIG editors.

There are consequences to using <i> and <b> instead of <em> and
<strong>. Being ambiguous, <i> and <b> are insufficient hooks for speech
CSS styling by the author, at least not without additional classes.)
Because they are so ambiguous, talking UAs will have to announce those
elements as "italic" and "bold" rather than applying any specific aural
styling such as a different rate or pitch of speech.  Because
announcements slow down reading speed much more than voice alterations,
it is likely that talking agent users will turn them off. Which means
their web experience will be ultimately degraded.

> Incidentally, this morning I came across this:
> http://www.elementary-group-standards.com/html/and-all-that-html5- 
> malarkey.html

> In particular, this caught my eye: “<b> has been deprecated.  
> Replacing <b> with <strong> suffices.”

> (I checked the schema, and, sure enough, <b> was not there. It turns  
> out that it wasn’t in the spec when I last reviewed that part of the  
> schema. It is in the spec now.)

> My point here is that the reaction was to simply replace <b> with  
> <strong>.

This data point doesn't demonstrate what you think it does. Andy Clarke
(the author) was talking about a particular example (literally one
use-case), not a wholesale replacement of all instances of <b>. To quote
the markup he's talking about:

> <p>This morning I returned from a (literally) flying visit to New York
> where I had the very real pleasure of visiting my friends at <a
> href="http://www.aol.com">AOL</a> and speaking at their Design and
> Programming Offsite event. The visit was a memorable one, not only
> because I am a huge fan of the work that AOL are doing and I was able
> to spend time with some of their hugely creative designers.
> (<b>Update:</b> There are <a
> href="http://www.flickr.com/photos/misterbiscuit/301182515/in/set-72157594383080722/">a few photos on Flickr</a>.)</p>

<strong> is a reasonable choice to replace <bold> /in that instance/.
(Whether it's ideal is debatable, but it's clearly better than <b>.)

> I think using span with a style attribute is a bad idea in this case.  
> Italicizing a word or two in a paragraph is not incidental style that  
> could easily be considered optional.

Surely it /is/ an incidental style, since authors, publication houses,
and style guides vary in their preferences about when to italicize.
Surely it is the distinctions between foreign and native languages,
between emphasis and non-emphasis, between titles and non-titles, and so
forth, that are non-incidental, and that italicization imperfectly
reflects. The typography is not the message; it is only its shadow.

> It is a more essential part of  
> the text that should be preserved when the content is formatted for a  
> different display environment possibly with a different font.

How would a different font conflict with its italicization? Did you mean
in a UA like Lynx that doesn't support CSS?

--
Benjamin Hawkes-Lewis