W3C home > Mailing lists > Public > www-tag@w3.org > September 2009

Re: versioning, robustness principle, doctypes etc

From: Karl Dubost <karl@la-grange.net>
Date: Wed, 23 Sep 2009 11:09:26 -0400
Message-Id: <626E0916-FFA5-42B3-BB4E-47C7CE9DF0EB@la-grange.net>
Cc: noah_mendelsohn@us.ibm.com, Larry Masinter <masinter@adobe.com>, "www-tag@w3.org" <www-tag@w3.org>
To: Henri Sivonen <hsivonen@iki.fi>

Le 17 sept. 2009 à 03:18, Henri Sivonen a écrit :
> Presumably specs shouldn't make old language features non-conforming  
> unless the old features are bad.

A feature was not necessary bad in the past, but appropriate for a  
specific historical, cultural or technological context.

> I can see a point that <font> has always been bad but it couldn't be  
> made non-conforming until CSS was available to authors. However, I'd  
> argue that when something is made non-conforming because it's bad  
> and there's a less bad replacement, the worse thing shouldn't be  
> made non-conforming until the replacement has been deployed.

It seems reasonable but difficult to properly estimate. Deployment is:

* available in a specification?
* implemented in a product? a majority of products? (then issues with  
threshold and metrics)
* used in many Web pages (how do we measure that? Specifically if the  
rate for content replacement is low)

> (In the case of Web languages, you almost always don't have the  
> liberty to update a language in a way that makes a previously  
> defined thing be processed as undefined.)


> Or the other way: If variability is bad, why would it be less bad  
> depending on when the content was authored?

Usage changed.

> For example, specifying the type="text/css" attribute on the HTML  
> <style> element is this kind of practice

not a good example:

> --specifying the attribute is just waste of typing,

* geeks authoring content by hands (with usually shortcuts)
* templates designers
* authoring tools implementers

The vast majority does not type it.

> network bandwidth,

… very specific cases, which are far, far, far away from the business  
reality of common web sites.

> parsing time

nothing compared to rendering

> and maintainer's reading attention.


> If a working group tried to update a Web language in such a  
> gratuitously incompatible way, the community would flip the bozo bit  
> on the spec and the WG and ignore them, so the specified  
> incompatibility wouldn't have a bearing on practical matters. Thus,  
> gratuitously incompatible changes aren't a useful motivation for  
> having version identifiers.

Or if the technology is becoming overly complex because it can't  
reinvent itself and become a babel tower, it will collapse. The issue  
as I see it in this discussion is often painted as right or wrong more  
than a share of benefits and issues on both sides of the argument.

For example for html5 versus html4, I know that having a version  
identifier is (in the current state of the specification) a must. The  
meaning of some elements (without thinking about processing) have been  
changed. And if you receive a document from a source you are trusting,  
without version identifier, it becomes hard to know which definition  
of the elements you refer to.

Karl Dubost
Montréal, QC, Canada
Received on Wednesday, 23 September 2009 15:09:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:03 UTC