- From: Karl Dubost <karld@opera.com>
- Date: Tue, 8 Nov 2011 14:13:57 -0500
- To: Larry Masinter <masinter@adobe.com>
- Cc: www-archive <www-archive@w3.org>, Daniel Glazman <daniel@glazman.org>, Peter Linss <peter.linss@hp.com>
Larry, (this is not an Opera position, but a followup on our "discussion" on twitter. adding Daniel Glazman and Peter Linss, CSS WG co-chairs) These are more thinking-out-loud than firm positions. Some issues with vendor extensions in CSS [1] (aka -vendor-something). Vendors extension have been created so that vendors could experiment the implementations of CSS properties [2] without cluttering the CSS namespace and be sure that when the different implementers reached an agreement on the way the property should be working, Web developers could use the unique value independently of any vendor specific property. That said there is a number of issues given the social and economic structure of the Web and its businesses. 1. CSS vendor extensions in stable product 1.a All browser companies are maintaining their CSS vendor extensions for a long time. They will stay there. The details on how long they stay must depend on each browser companies (to check). People can rely on them. 1.b -vendor- CSS properties are deployed in release products. not only in nightlies, alpha or beta version of products. 2. Web agencies budgets Web developers (web agencies) rely on -vendor- properties for their product with a fallback to the perceived final property. In the best case they do something like. -khtml-foo: bar; -moz-foo: bar; -ms-foo: bar; -o-foo: bar; -webkit-foo: bar; foo: bar; Once the project has been deployed they basically never update the CSS, because it is out of the initial client budget. 3. Production ready Web sites Because Web developers are using them in their production sites, they break depending on the user agent. Check for example the flexbox nightmare these days. "Worse" (given the circumstances), they tend to forget some vendor extensions, the Web site then look crappy on some browsers or completely unusable. 4. Market shares and new browsers If a company wanted to start a new browser with very few market shares, it will be very hard to gain traction because people will not put the extension of this specific new browser. SOME IDEAS for the future. * Nightlies only css vendor extensions should be working ONLY in nightlies or alpha versions * Issue: already deployed extensions it is unlikely browsers will do it. That would raise anger of many Web developers even if there is a kind of "I told you so" it was not stable. * -draft-* a unique -draft- or -unstable- for properties which are not stable. That way if implementations are breaking it discourages people to use them instead of relying on a semi stable rendering across browsers. * Issue: -draft- doesn't have the meaning anymore of do not use in production sites but more "use at your own risk" which we have seen people do not care. * Issue: What is the meaning of a property which is tested by a product but not yet submitted to the WG. [1]: http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords [2]: http://peter.sh/experiments/vendor-prefixed-css-property-overview/ -- Karl Dubost - http://dev.opera.com/ Developer Relations & Tools, Opera Software
Received on Tuesday, 8 November 2011 19:16:33 UTC