- 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