Re: W3C discussion of CSS prefixes

On May 15, 2012, at 3:03 PM, Larry Masinter wrote:

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

The term "pollution" in this context is referring to the days before we had vendor prefixes in CSS. In those days browser implementers (myself included) would simply add new properties, values and units to their CSS implementations. There was no distinction between an identifier that was part of the standard and one an implementer simply made up themselves, often in a vacuum. Sometimes to solve a genuine problem, other times because they simply thought it was a good idea.

Some of those identifiers were in shipped products and authors wrote content for them (and/or tools also generated content for them). Now, some 13 years later or so, we still have a few properties in CSS that were eventually added by the WG, not by design, but simply because there was too much existing content that relied on them. Some of these have confusing names and behaviors because they weren't thought out properly and didn't benefit from peer review and all the other goodness of the standards process. The 'word-wrap' property is an example.

Once the vendor prefix was instituted, the only identifiers that look like CSS identifiers are those sanctioned by the CSS working group (except for the legacy exceptions).

> 
> 
> 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'd say a combination of your third and fourth bullets (and maybe a bit of the fifth). 

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

The consequence is that the author's web page is fragile and will break (or at least fail to render as it once did) at some point in the future when the browser vendor who's prefixes they relied on remove the support for the prefixed version. Mozilla has been pretty good about deprecating support for prefixed properties once the feature is standardized, Microsoft as well to some extent. Apple tends to support the prefixes for way too long to prevent content breakage. This has led to many authors feeling that they can rely on the prefixed property forever.

The further consequence is that the author failed to create a web page designed to run in a standards compliant browser. They deliberately chose to target a specific browser in order to use a proprietary feature (or a proprietary experimental implementation of a feature in the standards process).

When authors do this, they should understand what they are doing. Many don't, often due to a lack of communication, a misunderstanding, and sometimes to other people advocating bad behavior. The authors writing content for a specific browser, should also research which other browsers implement similar proprietary (or experimental) features and target those as well. Some do, some don't.

Authors using experimental features also (IMO at least) have an obligation to update their content once the standard equivalent is available, or accept that their page will break.

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

I won't argue that there are issues with vendor prefixes, we all agree there. But I don't like using the term 'failure' when describing them. Fundamentally, they were an overwhelming success. They did what they were designed to do, protect the CSS language. Please let's not lose sight of that.

There is a way for authors to use proprietary and experimental features in a way that allows their page to transition to a standardized behavior once it's available, the cascade and forward-compatible parsing rules. Many authors don't do this right.

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

I never said authors shouldn't use them. I did say that when they use them, they should know what they are doing, do their best to use them right, and be extremely cautious about using them on production web sites. If they rely on them, they should expect their page to break at some point and on many browsers.

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

There is no plan that requires authors to use non-standard features. That's a choice the authors make, often for the wrong reasons and without understanding of the consequences of their actions.

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

We do manage extensibility in that there is a mechanism in place to add features to CSS that don't conflict with the standard or other vendor's extensions. There is a process in place to add those extended features to the standard. The CSS language has forward-compatible parsing rules and fallbacks to allow author experimentation with non-standard features in such a way as to maintain compatibility with standards compliant browsers.

If a vendor wants to add a proprietary or experimental feature to CSS outside the standards process, and not participate in the standards process, then there's not much we can do about it as a standards body.

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

My point here is that if a web page author creates a page that relies on -webkit- identifiers to function properly and ignores the behavior of that page on other browsers, they're simply not creating a standards compliant web page. It's no different than if someone writes a page that only works in IE due to the use of IE non-standard extensions, like ActiveX. They can do it, but it's not a behavior we should advocate, reward, or worry about breaking. Any expectation for that page to work in browsers other than the specific one it was targeted to is unrealistic. Frankly an expectation that the page will work on any other version of WebKit other than the one they tested against is also unrealistic.

> 
>>> 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 Wednesday, 16 May 2012 04:40:39 UTC