- From: James Graham <jg307@cam.ac.uk>
- Date: Thu, 03 May 2007 10:25:36 +0100
- 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 include: 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 useful. 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. [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-December/008889.html -- "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:15 UTC