W3C home > Mailing lists > Public > www-archive@w3.org > November 2011

CSS vendor extension issues

From: Karl Dubost <karld@opera.com>
Date: Tue, 8 Nov 2011 14:13:57 -0500
Message-Id: <9A8DC46C-1D05-4C00-9707-507958710DDE@opera.com>
Cc: www-archive <www-archive@w3.org>, Daniel Glazman <daniel@glazman.org>, Peter Linss <peter.linss@hp.com>
To: Larry Masinter <masinter@adobe.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:41 GMT