Re: Objection to HTMLWG ISSUE-144 Change Proposal #2 (keep u non-conforming)

On Fri, 1 Apr 2011, Aryeh Gregor wrote:
> The primary use-case for <u> is presentational markup, such as in 
> WYSIWYG editors, or when your client tells you "I want that text 
> underlined over there" and you aren't being paid to give him a lecture 
> on the importance of media independence.

This use case is already handled by CSS.

Underlining should not be encouraged since it conflicts with the 
de-facto hyperlink affordance. Therefore we should not have an element 
whose entire purpose is this presentation, even if we should have 
presentational markup, which we should not for reasons discussed 

> The claim that if we make <u> conforming we should also make <font> 
> <big> etc. etc. etc. conforming does not address the extensive rebuttal 
> of this argument that I wrote for the other change proposal (beginning 
> "<u> should not be invalid just because . . .").  I won't repeat it 
> here, but to summarize the most important points: the length savings of 
> <u> are greater than for most of the listed elements

<u> as proposed has essentially the same meaning as <i>, and there is no 
length saving between the "u" and "i".

> <u> is much more similar to <b> and <i> than to the non-conforming 
> elements listed

Indeed it is so similar that it is an unnecessary addition. The use case 
of "stylistically offset" is already entirely handled by <i>.

> and maybe we should make other presentational markup valid, but that can 
> be dealt with in a separate bug/issue and isn't relevant here.

This is a frequently claimed position, but making decisions like this on a 
case-by-case basis is seriously damaged language design. We have to take a 
holistic approach to the language or we will be forced to create a 
"compromised by committee" language that is internally inconsistent. 
Either we should decide we are making a presentational language, or we 
should decide we are making a media-independent, semantic-focused 
language. We cannot in good faith do both.

> The fact is, <b> is presentational markup too.

This is not a fact. As currently defined, the <b> element is 
media-independent: it is not just "bold" it is a definition that applies 
to multiple media in a way that an author can clearly distinguish when 
this element should be used vs other elements such as <i>, <strong>, 
<dfn>, et al.

> the specification says that <b> is to be used for "spans of text whose 
> typical typographic presentation is boldened", so it's defined solely in 
> terms of whether you want it to look bold.

This statement is provably false. It isn't defined "solely in terms of 
whether you want it to look bold", since the mention of bold is literally 
only one of 3 non-normative examples of the actual definiton', which is "a 
span of text to be stylistically offset from the normal prose without 
conveying any extra importance" (as contrasted with <strong> and <i>, 
which in the first case conveys importance and in the second case conveys 
text that is stylisticly offset but without the "no importance" rule).

> Yes, you can quibble that "b { font-weight: normal; font-variant: 
> small-caps }" would be correct according to the official definition, but 
> that's a purely academic point, because nobody in his right mind is 
> going to do that, ever.

That's false. I've done it quite often, exactly as per the spec's 

> Just because there might be someone out there who's using 
> <b> (or <i> or <sub> or <sup> or <small> or anything like that) for an 
> effect other than the normal one, and the spec technically allows this, 
> doesn't mean that it's somehow less presentational in the real world.

What matters as to whether it's presentational is what the spec defines it 

> The fact that the definition allows room to use <b> other than for 
> bolding things is not meaningful -- it's playing word games in an 
> attempt to make it not look like it's presentational

No, the spec's definitions are not "word games". If they were, then it 
wouldn't matter what the spec said anyway. The spec's authoring 
conformance definitions are normative descriptions of best practices for 
authoring and not games. The spec's semantic definitions are normative 
descriptions of the best practices for authoring and not games.

> because of a long-standing crusade in the web standards community 
> against presentational markup.

It's not an arbitrary crusade; presentational markup has hurt 
accessibility, maintainability, performance, device-independance, machine 
processing, et al, a great deal. Furthermore it's an issue where authors 
have shown an inability to deal with subtlty.

> Presentational markup is not bad per se.  Some typographical effects are 
> commonly required but have no particular meaning.  Sometimes authors 
> just want some text to be bold or italic or underlined, and don't want 
> to have to reason about *why* they want it in some abstract fashion.

With bold an italics, there is less harm caused by such thinking than by 
underlining, and the elements can be defined in such a way that the 
majority of uses will be conforming even if the author doesn't really know 
why they desire that presentation.

However, underlining is not a common typographic effect except for 
indicating hyperlinks, and for this reason <u> is quite different than <b> 
and <i>. Thus the parallel in the above argument is inappropriate.

To put it another way: misuse of <i> and <b> usually does no more harm 
than removing semantic information from the markup -- e.g. using <i> 
instead of <em> does no more harm than simply not having used either. But 
using <u> can cause practical usability difficulties.

> WYSIWYG editors are the only way that almost anyone edits any rich-text 
> format, including HTML, because presentation does not require reasoning 
> about anything you can't see before your eyes. Everyone can understand 
> the difference between "this makes things bold" and "this makes things 
> italic".  But would *you* be able to tell when you should use something 
> that "represents stress emphasis of its contents" vs. "represents strong 
> importance for its contents", if you didn't already know one was <em> 
> and one was <strong>?

Yes, of course. Stress emphasis and importance are very distinct concepts.

That the state of the art in editor development is unable to currently 
provide the full gamut of HTML semantics to users of editors is not a 
reason to add <u>, since the state of the art is at least more advanced 
than that (if not so widely deployed). (It _is_ a reason to add <font 
style=""> in a manner only allowed for WYSIWYG editors, which we had done 
many years ago and removed for various reasons again many years ago.)

> So the real use-case here is presentation, and that's a completely valid 
> use-case.  Without <u>, we have to use <span style="text-decoration: 
> underline"> or <span class=u> or something like that.

Or just <i> and a simple style rule in the CSS.

> Since underlining is one of the commonest stylistic effects available, 
> there's no reason to declare an existing, fully-functioning shortcut 
> verboten.

Underlining is an archaic stylistic effect in general, and is not one to 
encourage on the Web.

The first hit for the word "underlining" on Google:

...explicitly indicates that italics and underlining are equivalent. This 
argues strongly that <i> should be used for those semantics and that CSS 
should be used to control the style.

The first hit for "fashionable typography" on Google: a diatribe on how underlining is antiquated and should only be used 
for hyperlinks.

> On the other hand, if <b> and <i> are actually semantic and not
> presentational, then so is <u>.

Whether they are semantic or presentational depends entirely on their 
definition. If we add <u>, we could define it either way. That's a given. 
We could define <u> as meaning "text spoken by a baby", or as representing 
"names of fruit".

> The proposed text closely follows the pattern set by <b> and <i>'s 
> current definitions.

This is merely evidence that <u> adds nothing that isn't handled by those 

> Even if it were the case that "a span of text to be stylistically offset 
> from the normal prose" is already represented by <i>, there's no reason 
> given why we can't have two elements with the same semantics.

There's no benefit to doing so either, and there are multiple negatives; 
for example it leads to arguments about which element is appropriate (this 
is why we dropped <acronym>, which was redundant with <abbr>), and in the 
case of <u>, it has default styles that are considered "antiquated" and 
confusing for users.

> Confusing authors is an important concern here, but it's one that speaks 
> in favor of making <u> conforming.  Authors are all familiar with word 
> processors and other formatting systems in which bold, italic, and 
> underline are all prominently available right next to each other.  
> Allowing only bold and italics, but not underlining, is sure to be 
> extremely confusing to authors.

All are already allowed, as is "blue" and "small-caps" and "sans-serif", 
and so forth, via CSS.

> As far as underlines being confusing on the web because of links, I 
> agree with that, but authors still want them.  This is clear when you go 
> to any WYSIWYG web editor, since in my experience, they all have 
> underline buttons.

They also have "text color" buttons, but we don't support that. In 
general, just because a feature is commonly provided doesn't mean it's 
widely used, just because a feature is widely used doesn't mean it's 
widely desired, and just because it's widely desired doesn't mean it's 
good practice. Authoring conformance criteria should reflect best 
practice, not existing practice. (It's implementation conformance criteria 
that should match existing practice.)

> Nobody has provided any reasoning to suggest that making <u> invalid 
> will discourage the use of *underlining* -- if we look at how major web 
> applications are written, it seems much more likely that people will 
> just switch to <span style="text-decoration:bold"> or <span class=u>.

It's hard to provide numbers either way, but in general the assumption 
behind having authoring conformance criteria at all is that they are a way 
to convey best practices to authors. Authors can naturally ignore these, 
either by using other mechanisms like style="" or class="" in manners that 
are equally media-specific, or indeed by using <u> despite it not being 
conforming. If the fundamental assumption that authoring conformance 
criteria can influence author behaviour for the better is false, then our 
whole approach to how we write HTML should change. IMHO, such a decision 
is out of scope of this issue.

> I know that when the issue of moving MediaWiki to future HTML versions 
> came up once a few years ago, then-lead developer Brion Vibber said 
> something to the effect of "If some future version of HTML is stupid 
> enough to ban <b>, we'll just automatically rewrite it to <span 
> style='font-weight: bold'> to keep the validator happy."

This is a natural problem in a situation where a presentational format (in 
this case the MediaWiki format) is mapped to a semantic format (in this 
case HTML). If we want to make it possible to use HTML as a media-specific 
presentational language, then we have much work to do beyond just adding 
<u>. Again, this is not something we should do piecemeal; this kind of 
overarching change in design direction should be made in conjunction with 
its implications, otherwise we end up with a highly inconsistent, 
comprised-by-committee design.

> Authors who care about validation are not deterred by having to write 
> longer markup to achieve the same effect.

This is a massive generalisation. While there are indeed such authors, and 
such authors cannot be taught about best practices solely through 
validators and conformance requirements, there are also those for whom 
conformance requirements are used as a stepping stone to a fuller 
understanding of the basic design of the language.

> So ruling out <u> will only discourage the use of the <u> element 
> itself, not the use of underlining.

It is, as they say, a start.

> Given that underlining will happen anyway, there's no reason to make 
> markup more bloated so that web pages are harder to read.

One could easily say "given that pages will be made inaccessible anyway, 
there's no reason to make the language unintuitive in an effort to make 
authors write more accessible content". There _is_ a reason, indeed many 
reasons, which have been discussed at length.

> "The best practice (for accessibility, maintainability, and semantic 
> analysis) is widely recognised to be the separation of semantics and 
> styles, which argues against presentational markup such as in this 
> proposal."
> No evidence or reasoning is provided to back this statement up.

Accessibility: semantics are easier to map to media-specific presentations 
(e.g. speech synthesis) than are media-specific styles (e.g. visual 
styles) because to map a media-specific style to another medium's styles 
one has to first determine the meaning of the styles, which is an unsolved 
computer science artificial intelligence problem. For example, does the 
underline indicate importance, which should be mapped to a more deliberate 
speech pattern, or is it merely an aethetic effect, which should not map 
to anything? Does it indicate a link, which should be clearly denoted 
(e.g. with audio icons), or does it indicate a stress emphasis, which 
should merely be mapped to a slightly altered voice? Given the state of 
the art, separating semantic markup from styles is therefore the best 
practice for accessibility.

Maintainability: Should the author (or the author's employer/client) 
decide that actually underlining all the headings was a mistake and they 
should instead be italics, the change can be trivially implemented if the 
markup is semantic rather than stylistic: simply change headings to be 
italics rather than underlined. If, instead, a stylistic element is used 
within the pages each time an underline is required, the author is going 
to have to go through every part of every page changing just the 
underlines that correspond to headings. This would take orders of 
magnitude more time. Given this, separating semantic markup from styles is 
therefore the best practice for maintainability.

Semantic analysis: As with accessibility, the ability for a computer to 
distinguish underline when used for a proper name mark, when used to 
indicate a hyperlink, when used to indicate emphasis, when used to 
indicate italics in a manuscript, when used to indicate a spelling error, 
and so forth, requires artificial intelligence at the cutting edge of 
natural language research (or beyond). To allow semantic analysis to be 
performed by those who do not have access to the latest and greatest 
research, and indeed to enable semantic analysis to be done at all in many 
cases given the state of this research, the input markup must include at 
least basic hints as to the meaning implied by the presentation. As such, 
separating semantic markup from styles is therefore the best practice for 
enabling semantic analysis.

(Note that the above are specifically problems with the <u> element!)

These principles (and others that don't necessarily apply specifically to 
the case of the <u> element, such as performance) have long been 
recognised. The Web Standards Project, for instance, has been saying this 
since before 2001:

 "Each layer of a Web document was designed as part of a whole framework 
 to achieve this balance. This is why the separation of structural HTML 
 or XML from the presentation of a document is so important"


 "Separation of presentation and content (or "separate content from 
 presentation", a special case of the form and content principle) is a 
 common idiom, a design philosophy, and a methodology applied in the 
 context of various publishing technology disciplines, including 
 information retrieval, template processing, web design, web development, 
 word processing, desktop publishing, and model-driven development."

As far back as 1998, this was being explained in tutorials:

 "One of the nifty little concepts that HTML inherited from its rich 
 daddy SGML, is the idea that document structure and document presentation 
 should be separate."

Even people who would probably agree with the proposal to add <u> to the 
language agree with the principles laid out above:

 "It is absolutely a best practice to separate your content, presentation, 
 and behavior layers as much as possible."

The best practice (for accessibility, maintainability, and semantic 
analysis) is widely recognised to be the separation of semantics and 
styles, which argues against presentational markup such as in this 

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 4 April 2011 05:51:51 UTC