RE: W3C discussion of CSS prefixes

OK, I see the problem is:

> Authors should write their style sheets using the unprefixed property,
> and only add a prefixed version of the property (below the unprefixed
> one) if they discover a bug or inconsistency that they need to work
> around in a particular browser.

Getting authors to do anything unnatural  just by writing a spec is hopeless. There are too many of them, and they don't read standards, and often work by trial-and-error.

Getting browser makers to agree to do something is possible, if it is in their interest. Adding incentives to authors to write stuff that is standard rather than specific to their browser is unnatural,  but there are fewer browser makers and they're at the table. It does require asking them to forego playing "browser wars", and adding some encouragement to authors.

There is *some* chance of influencing author behavior if browsers give consistent feedback.

So, for example, if you could get browser vendors to display anything that uses an unprefixed but non-standard feature with a different-colored border, or a 'developer' menu, or a "ADVANCED HTML FEATURE" description or something.  I don't know what the incentive needs to be, but silently accepting non-standard features which look like they are unprefixed does seem to encourage author behavior leading to pollution.

But the browser makers really need to act in concert to fix this, and the fix is likely different for CSS (cascading) and XML (XML-ER) and HTML (tag soup).


-----Original Message-----
From: Linss, Peter [mailto:peter.linss@hp.com] 
Sent: Wednesday, May 16, 2012 8:43 AM
To: Larry Masinter
Cc: Florian Rivoal
Subject: Re: W3C discussion of CSS prefixes


On May 16, 2012, at 12:26 AM, Larry Masinter wrote:

> I agree: the question is, for any deployment scheme, does it work in preventing pollution, and in which circumstances.
> The previous (prefix-less) system caused (or didn't prevent) pollution.
> 
> But http://lists.w3.org/Archives/Public/www-style/2012May/0125.html doesn't propose going back.

In effect it does. Under this proposal authors are encouraged to write style sheets using the un-prefixed versions of new identifiers from the first day an experimental implementation exists. Even though the browser accepts the prefixed version.

This will result in an immediate installed base of content using the first proposed syntax and behavior of any experimental feature (and relying on any bugs in the first implementation). Once that has taken hold, implementers (and therefore the WG) will be reluctant to change the feature for fear of breaking existing content.

Take for example CSS gradients. The syntax went through a number of revisions, many of which were not backward compatible. Each browser vendor who delivered an experimental implementation did so against a different version of the draft and with different syntax or behavior. To further complicate things, the WG decided to again change the syntax just before entering CR, even though the change was incompatible with every deployed experimental version in existence.

The end result is a cleaner syntax, easier for authors to understand and explain. The WG was only able to make such changes because existing content was using the prefixed versions of the property, which did not have to change. This is precisely what prefixes were designed to allow.

Florian's proposal removes the ability of the WG to use experimental implementations for what they were intended for, to learn what works and what doesn't, and then make changes as needed.

For the simplest gradient, instead of:
background-image: linear-gradient(to bottom, black, white);

we would have been stuck with:
background-image: gradient(linear, left top, left bottom, color-stop(0, black), color-stop(1.0, white));

> 
> So how does it cause pollution? It provides deployment scenarios which seem reasonable to me, in which circumstance will you get what kind of pollution any more or worse than the currently documented deployment plan?
> 
> With Opera implementing -webkit- prefixes because it was unreasonable to expect site designers not to use vendor prefixes in production code, with that happening, you could say that the current deployment plan for CSS vendor prefixes "causes" (or at least doesn't prevent) pollution.
> 
> I'm not sure what I'm missing here. Probably the obvious.
> 
> -----Original Message-----
> From: Linss, Peter [mailto:peter.linss@hp.com] 
> Sent: Tuesday, May 15, 2012 9:38 PM
> To: Larry Masinter
> Cc: www-tag@w3.org; Florian Rivoal
> Subject: 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 19:07:35 UTC