Re: versioning, robustness principle, doctypes etc

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.)

why?


> 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