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
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
