- 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>
[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