- 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