RE: W3C discussion of CSS prefixes

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

To which you replied:
> 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.


Could you explain "pollution" ?  I don't see "pollution" as an outcome in any particular workflow, but I'm not sure what it means anyway. "stuff you don't want", I suppose, but what is unwanted where?


Larry
> 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, .....
>  All the normative text about prefixes is either in a spec or a WG note under w3.org/TR.

I'm not sure how the deployment plan is "normative" but fine. If it's not too much trouble, could someone point us to the normative text?  


====
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.
====

I was trying to understand which held in the case of Opera implementing webkit vendor prefix:

* Opera's implementing webkit prefixes is consistent with the deployment plan
* The deployment plan was ambiguous, doesn't speak to this
* The deployment plan wasn't ever agreed or wasn't communicated properly
* The deployment plan was misunderstood
* The deployment plan was understood but ignored because it failed


I'm not sure which you think holds. I think it sounds like the last: Web authors used -webkit- prefix, to the point where (You say) "Web authors use them at their own risk"). But there's no consequence to using these features, which worked fine on the devices they cared about. 

So I would call this a failure of the deployment plan: it expected a large body of users to follow guidelines that are unnatural, and prevents them from using features that are needed to get the effects they want on devices they care about.

> The fundamental problem here is when authors use non-standard features and expect them to work for all time across multiple browsers.

Expecting authors not to use non-standard features is unrealistic.  And the authors who used -webkit- prefixes didn't care about opera users. It's only opera users who care. So if the deployment plan requires authors not to use non-standard features, it's not a good plan.

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

I think we have to manage extensibility.

> 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 disagree that this analogy is "essentially no different", it is different in many aspects.

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

Received on Tuesday, 15 May 2012 22:07:56 UTC