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

[Benjamin Hawkes-Lewis]

Henri Sivonen wrote:

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

Well the WYSIWIG paradigm has been dominant in user-space. But I have
pointed to alternatives like Lyx and Mellel. Those seem to be successful
at bringing semantic thought-processes into the word processing sphere,
where there has traditionally been less payoff. (Although now that ODF
and PDF are becoming accessible formats, some sort of semantic authoring
will have to become part of the WYSIWIG workflow.)

Whereas desktop applications are gradually innovating, much web
development has been obsessed with trying to mimic desktop applications
as closely as possible, rather than focusing on the potential of the web
as a medium. In other words, interface conservatism has been an
end-goal.

> In theory, that's <em>. But in  
> practice the choice between <em> and <strong> is motivated by the  
> default visual rendering.

In so far as this is true, it is dependent on people having learned the
"proper" visual rendering for foreign phrases, film titles, warnings,
and so forth, partly through reading print and largely through word
processing. While people may not consciously think about why they are
using bold or italic, some part of their brain must know, since
otherwise they would get it wrong exactly half the time. Extending that
learned behaviour to the web has certain advantages, but it also has
severe disadvantages. Because people are familiar with concepts like
"emphasis", "foreign word", and "book title", one could build an
interface around that instead, just as much around their familiarity
with the [I] button.

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

Well, yes, we'd get a higher payoff from creating a reference
implementation and filing bugs on existing editors.

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

<em> and <strong> are specific to emphasis. <i> and <b> are not. If you
want to apply one style for emphasis, another for foreign language
phrases, and another for citations (say), you'll therefore need to
employ additional classes. In which case, you might as well have just
used semantic markup in the first place.

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

<em> and <strong> have been heavily misused thanks to exceptionally
inappropriate tools. But they've been /less/ heavily misused than other
HTML elements, such as <table> and <blockquote>. I think a good, if
depressing, question to think about is this: will HTML5 documents
generally continue the web's existing traditions of broken tag content
using tables for layout? If so, we might as well throw /all/ semantics
into microformats, which is practically what XHTML2 is doing, since all
elements defined in the spec will continue to used for their
presentational effects not their semantic import. The different
semantics of <em> and <i> would be the least of our problems.

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

Documents authored by badly designed tools are likely to be inaccessible
in other ways too. You'd really have to take a sample of markup that is
generally accessible. I suspect you'd find that the <em> and <i>
distinction is rather more common there.

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

Not really. If tool vendors used <em> and <strong> for italics and bold,
then AT and talking browser vendors would have to implement the same
annoying techniques for exposing <em> and <strong>, since voice emphasis
would be inappropriate.

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

Agreed on column width and on the general idea (not all styles are
necessarily equal). But what about the use of different typefaces for
<code> and <samp> and so forth? What about the symbolic use of different
type sizes in mathematical text? What about the use of type size for
emphasis, or for Ruby annotations? 

--
Benjamin Hawkes-Lewis