W3C home > Mailing lists > Public > www-style@w3.org > December 2011

RE: "-draftX-" prefix

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 7 Dec 2011 02:48:31 +0000
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F017829033B31C7@TK5EX14MBXC295.redmond.corp.microsoft.com>

[Daniel Glazman:] 
> Le 05/12/11 23:57, Tab Atkins Jr. a écrit :
> > It seems clear that the major prefixing failures
> > (Transition/Animations/Transforms) are caused by specs progressing too
> > slowly, so fixing that directly seems to be the correct thing to do.
> Sorry, it does not seem that clear to me the specs are the original root
> of the problem. For me, the original root of the problem is experimental
> prefixed properties shipped with documentation as a non- experimental
> feature, immediately used in the wild by a large number of web authors,
> and shipped before standardization happened in the WG.
If the alternative is features not achieving any exposure beyond the tiny coterie
of people who use nightlies and previews, I don't think it will result in better 
standards. Yes, millions download some preview builds; but the feedback thus 
collected - much of it privately - is simply not equivalent to the public, 
independent evidence of thousands of pages using a new feature. (And I doubt the 
latter would be created if new features were only available in specialized 
non-release builds).

Most importantly, I don't understand why tens of thousands of authors voting 
for a feature with their sites and CSS editors is a horrible problem that 
needs fixing, or a situation to be avoided. I would argue it should be our goal
for as much of our work as possible. A process that treats early success as
a problem to be prevented or ignored is at risk of becoming irrelevant.

Not only does real-world use of a new feature feed back into the spec, it can
inform the WG about use-cases it didn't think of, or re-prioritize the use-cases
it did consider. The volume of usage of a new feature is also arguably one of the 
most relevant indicators we have of what needs to be standardized in a given
charter period and why. Cutting or severely curtailing such a line of feedback 
seems counter-productive in this respect. 

You may argue that such features are not 'experimental' anymore. If by experimental
you mean 'used and tested by the smallest number' then yes. They're not. But on 
balance I think that implementation experience - and implementation competition - 
is very valuable. It's a feature, not a bug that needs fixing.

Should we no longer ship such 'experimental' features I would also be concerned about
the lack of incentives that would result. If massive use of a prefixed feature in the 
wild is not sufficient for standardization to follow in an efficient and timely manner, 
it's unclear how not releasing the feature altogether would result in better standards
in a more timely manner.

Received on Wednesday, 7 December 2011 02:49:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:08 UTC