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

On Jan 9, 2007, at 23:29, Benjamin Hawkes-Lewis wrote:

> 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.

Sure. But is it realistic to expect this to change? What expected  
payoff is there for tool vendors for providing a non-deceptive UI for  
<em> and <strong>?

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

Part of the overall "test" is that such UIs haven't been launched  
with success in the last 14 years.

>> <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>. ;)

More to the point, there is utility in being able to typeset a word  
or two differently in a paragraph. In theory, that's <em>. But in  
practice the choice between <em> and <strong> is motivated by the  
default visual rendering.

Therefore, the situation is that there are two "semantic" elements  
for making a piece of text different: <em> and <strong>. The choice  
depends on the preferred default visual rendering: italic vs. bold.  
In practice this isn't any different from saying that the semantics  
of <i> and <b> are to set text differently with default visual  
renderings being italics and bold.

>> 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?

Perhaps, but what's the payoff of vehemently communicating more about  
this? Is it worth it? Would there be a different way to get the same  
payoff?

> 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.)

<em> and <i> are exactly as stylable. <strong> and <b> are also  
equally stylable.

> 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.

When an author presses command-i, he may not even know what markup is  
generated. The choice between <i> and <b> vs. <em> and <strong> is  
pretty much up to chance. This means that in *practice* <em> and  
<strong> are, on the real Web out there, about exactly as ambiguous  
as <i> and <b>. Since voice browsers aren't truly able to extract  
significance out of the choice of <em> vs. <i> (as the choice of  
element is largely up to chance), I conclude that reading them  
differently from each other isn't a particularly useful idea.

If <i> and <b> have been implemented in an annoying way for the aural  
media, isn't the conclusion that it would even be rational for  
WYSIWYG tool vendors to use <em> and <strong> for italics and bold to  
avoid annoyances on the aural media? (Moreover, as currently defined,  
<em> and <strong> have more versatile content models in XHTML5, which  
means tool vendors would have an additional incentive to emit those  
elements.)

>> 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.

Granted, but italics and bold are more sticky properties of the text  
than e.g. font family, font size or column width, so it is a mistake  
to treat all style properties as being equally incidental and  
expendable.

>> 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?

It wouldn't. My point was that italic and bold are stickier or closer  
to being part of content than the font.

> Did you mean in a UA like Lynx that doesn't support CSS?

No, but Lynx supports the point that <i> and <b> are different from  
other text foremost and italic and bold if possible. The copy of Lynx  
available to me renders <i>, <b>, <em> and <strong> all in the same  
way but differently from normal paragraph text.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 10 January 2007 00:31:34 UTC