W3C home > Mailing lists > Public > www-html@w3.org > May 2007

Re: Cleaning House

From: James Graham <jg307@cam.ac.uk>
Date: Thu, 03 May 2007 10:25:36 +0100
Message-ID: <4639AA90.7020309@cam.ac.uk>
To: "Patrick H. Lauke" <redux@splintered.co.uk>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, www-html@w3.org, public-html@w3.org

Patrick H. Lauke wrote:
> Quoting Boris Zbarsky <bzbarsky@MIT.EDU>:
>> Just to reiterate, there are two questions here:
>> 1) Should documents containing <b> and <i> be conforming HTML5 documents?
>> 2) Should the HTML5 specification normatively specify parsing of
>>    <b> and <i> that is compatible with existing content?
> I would say:
> 1) no - instead, define better elements that cover those situations in 
> which the elements in question are used as a last presentational resort, 
> for lack of a more semantic equivalent; and if they ARE used purely for 
> presentational reasons ("i just like how that word looks in italic"), 
> suggest generic approaches such as an appropriately styled <span>.

FWIW I spent some time arguing this point of view on the WHATWG list. I 
eventually came to the conclusion that I was wrong and that having some 
presentational elements in the language to cover common typographic 
conventions is a positive thing. Some of the reasons I changed my view 

a) Having a *few* typographical elements for *common* typographical 
conventions alleviates the abuse of semantic elements for non-semantic 
purposes. For example blindly replacing <em> with <i> only serves to 
make it harder for UAs to be sure that <em> is being used to indicate 
emphasis. By encouraging authors who are not consciously specifying a 
semantic rather than a presentation to use non-semantic elements rather 
than mis-use semantic ones we can hope to prevent the dilution of the 
semantics in "semantic" elements to the point that they are no longer 

b) The alternative you suggest; enumerating all common typographical 
uses of a style and adding one element per use would increase the 
complexity of the language markedly. The simplicity of the language is 
one of the chief virtues of HTML: it makes it very easy to learn. I do 
not think it would be wise to throw that away.

c) Short, easy to remember, typographical elements do not have any 
disadvantages compared to <span style=""> and have a few advantages. In 
each case the elements are just as easy to ignore for UAs which do not 
support the typographical style. Moreover short, easy to remember 
elements have several advantages; they are short to type, do not reply 
on a specific styling language and, being part of the language, are more 
likely to be used where a semantic element might otherwise be abused.

See e.g. [1] for more of my reasoning here.

At present the WHATWG spec puts "semantic fig leaves" over these 
elements, something which I believe to be unnecessary. However if this 
turns out to be my biggest disagreement with the final spec, I will 
consider it a major success.

> 2) yes - but make it clear that it's a special backwards-compatibility 
> concession, and that it does not ratify the use of those elements; it 
> could then even include the elements that Anne touched on, like <center>.

The WHATWG spec does in fact specify parsing for all legacy HTML 
elements including those which are not mentioned anywhere else in the spec.


"Instructions to follow very carefully.
Go to Tesco's.  Go to the coffee aisle.  Look at the instant coffee. 
Notice that Kenco now comes in refil packs.  Admire the tray on the 
shelf.  It's exquiste corrugated boxiness. The way how it didn't get 
crushed on its long journey from the factory. Now pick up a refil bag. 
Admire the antioxidant claim.  Gaze in awe at the environmental claims 
written on the back of the refil bag.  Start stroking it gently, its my 
packaging precious, all mine....  Be thankful that Amy has only given 
you the highlights of the reasons why that bag is so brilliant."
-- ajs
Received on Thursday, 3 May 2007 09:27:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:21:02 UTC