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

Re: Cleaning House

From: James Graham <jg307@cam.ac.uk>
Date: Wed, 02 May 2007 23:44:49 +0100
Message-ID: <46391461.3060606@cam.ac.uk>
To: "Patrick H. Lauke" <redux@splintered.co.uk>
Cc: www-html@w3.org, public-html@w3.org

Patrick H. Lauke wrote:
> 
> Maciej Stachowiak wrote:
> 
>>> 1.  How long do we need to continue to support deprecated tags?
>>
>> Probably forever. At least, I don't think the content using them will 
>> disappear entirely from the web any time soon, if ever.
> 
> But the content using them is written in older (<5) versions of HTML, so 
> why is that relevant (unless you want 100% backwards compatibility, in 
> which case you should also reintroduce things that have already been 
> dropped, like TT, BIG, STRIKE, S and U). Treat them as unrecognised 
> elements, rather than ratifying their use for yet another standards 
> round...

Browser vendors have made it clear that all those tags will still be 
supported in releases for the foreseeable future. There is nothing this 
working group can do about that; we have no sticks and I can't imagine 
what would constitute a appetising enough carrot. Therefore we have a 
binary choice: specify how the deprecated and obsoleted features should 
work in UAs and so make the web better by improving interoperability or 
refuse to specify how they should work and maintain the status quo where 
any interoperability that happens to exist is the result of tedious, 
error prone, reverse engineering of market-leading implementations.

Note that, as has been said before, this is an entirely separate issue 
from whether we should make these tags conforming in documents. For 
example, there is no need for a document containing <big> to pass a 
conformance check just because UAs have some behavior when they 
encounter it.

Creating a culture where authors naturally value conformance checking, 
plus sound arguments as to /why/ using deprecated/obsolete features and 
invalid markup is bad /for the author/ are the best carrots we have to 
make authors clean up their own markup output. This has worked in the 
past; much of the current trend toward clean HTML and CSS has come from 
reasoning based on self-interest e.g. [1]. I believe this is the best 
approach to take going forward.

[1] http://www.adaptivepath.com/publications/essays/archives/000266.php


-- 
"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 Wednesday, 2 May 2007 22:46:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:10 GMT