[whatwg] contenteditable, and

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

> 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 . But in 
practice the choice between and is motivated by the 
default visual rendering.

Therefore, the situation is that there are two "semantic" elements 
for making a piece of text different: and . 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 and 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.)

and are exactly as stylable. and 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 and vs. and is 
pretty much up to chance. This means that in *practice* and 
 are, on the real Web out there, about exactly as ambiguous 
as and . Since voice browsers aren't truly able to extract 
significance out of the choice of vs. (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 and 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 and for italics and bold to 
avoid annoyances on the aural media? (Moreover, as currently defined, 
 and 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 and are different from 
other text foremost and italic and bold if possible. The copy of Lynx 
available to me renders , , and all in the same 
way but differently from normal paragraph text.

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

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