[whatwg] contenteditable, <em> and <strong>
hsivonen at iki.fi
Wed Jan 10 00:31:34 PST 2007
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
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
> Yes, it's a bad habit picked up from WYSIWIG word processing. If
> were still habituated to typewriters you'd be insisting on the
> 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>
>> <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
> There are consequences to using <i> and <b> instead of <em> and
> <strong>. Being ambiguous, <i> and <b> are insufficient hooks for
> CSS styling by the author, at least not without additional classes.)
<em> and <i> are exactly as stylable. <strong> and <b> are also
> Because they are so ambiguous, talking UAs will have to announce those
> elements as "italic" and "bold" rather than applying any specific
> styling such as a different rate or pitch of speech. Because
> announcements slow down reading speed much more than voice
> 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
>> 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
>> 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.
hsivonen at iki.fi
More information about the whatwg