Re: W3C discussion of CSS prefixes

On May 10, 2012, at 1:04 AM, Larry Masinter wrote:

> I like Florian's proposal
> 
> [2] http://lists.w3.org/Archives/Public/www-style/2012May/0125.html

Except for the fundamental problem that it defeats the primary purpose that vendor prefixes were invented for in the first place, namely, pollution of the core CSS namespace by browser implementers outside the standards process.

I think this proposal is a non-starter.

I have a similar issue with the '! (vendor)' proposal.


> it answers many of the questions I raised in: 
> http://lists.w3.org/Archives/Public/www-tag/2012Apr/0223.html
> about the problems with the deployment plans
> http://wiki.csswg.org/spec/vendor-prefixes

First, note that the wiki page above is merely a collection of information, not a normative reference from the CSS working group. In fact, a large part of the content on that page was done by someone who's not even a member of the WG. All the normative text about prefixes is either in a spec or a WG note under w3.org/TR.

Second, there _is_ a deployment plan for vendor prefixed identifiers, add them to a spec. Once the spec is in CR, or prior to that, the working group has blessed the property or value as stable and demonstrated at least two interoperable implementations with test suites. Then use of the identifier without prefixes is then allowed. Once the un-prefixed version is available, the normal CSS cascade allows backward and forward compatibility. That mechanism isn't generally available in other languages.

Until the identifier is part of a stable spec, it's a proprietary (and often unstable) feature and generally lives outside the scope of the W3C. Web authors who use them do so at their own risk. They are, by definition, creating a non-standard, non-conforming web page.

The fundamental problem here is when authors use non-standard features and expect them to work for all time across multiple browsers. I don't think that's a problem that's solvable by a standards process, except to make the feature available as part of a standard. It's essentially no different than if someone wrote a "web app" using ActiveX controls and got upset or surprised that it didn't work in non-IE browsers.

> 
> 
> I think in general that an extensibility method needs a credible 
> deployment method. CSS, HTML, HTTP and many other formats
> have extensibility methods, most of which wouldn't stand up.
> 
> So applying the lesson from CSS vendor prefixes to other extensibility
> mechanisms would be worthwhile.
> 
> Larry
>

Received on Tuesday, 15 May 2012 17:49:48 UTC