RE: W3C discussion of CSS prefixes

> Today, there is enough content using the "-webkit-gradient(linear..."
> syntax that webkit vendors have decided to never drop it, and other
> vendors are considering supporting it was well in addition to the standard
> syntax.

At some point we move from "reality" to "prediction".  Vendors implement stuff on schedule to meet current demand, and it's hard for a standards group to tell a shipping product to stop shipping.

But the point when implementors can be accused of "bad faith" is when they announce FUTURE policy about what they will do forever, in which that future policy is in contradiction to their previous policy agreements.

What I think we need is:

* A deployment policy that doesn't require asking authors to do anything other than "use what works" 
* Consensus by (leading) browser makers that they will follow the deployment policy, including visible, 
   public statements as to their intention in the future

The place where the current plan broke down, in my opinion, is when browser makers announced they would NEVER drop support for some current prefixed properties. This moved us from "paving the cow paths" into "browser wars" territory.

I think it's even reversible. Get the horse back into the barn. Browsers that said they would keep the prefix forever could announce 

"We didn't mean NEVER.  Our policy is now that we may continue support of -webkit- prefixes 5 years after there is a Recommendation for an un-prefixed equivalent, but if so, we'll change the web page border to some other color. And after 10 years, we'll drop support of the prefixed version entirely."

Even a little bit of back pressure would go a long way.

Larry


-----Original Message-----
From: Florian Rivoal [mailto:florianr@opera.com] 
Sent: Friday, May 18, 2012 9:52 AM
To: Larry Masinter; Linss, Peter
Cc: www-tag@w3.org
Subject: Re: W3C discussion of CSS prefixes

On Wed, 16 May 2012 06:37:45 +0200, Linss, Peter <peter.linss@hp.com>
wrote:

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

Unfortunately, I don't think the current policy actually succeeds at
preventing pollution. For two reasons:

1) Authors actually use the prefixed properties, and we can (and have)
end up with fairly large amounts of content using a prefixed syntax.
A large part of this content uses the prefixed syntax of a single
vendor (the one who introduced it first), without fallback.

This has happened with -webkit- prefixed properties, to the point
where webkit vendors have decided they would never drop support
for the prefixed syntax of some properties.

As you said, we may never be rid of text-wrap, even if we
introduce a better name side by side. But with prefixes,
we may never be rid of display:-webkit-box, or -webkit-gradient,
or -webkit-border-radius. I don't like these names any better.

Yes, these names can easily be identified as special, but as long
as we are stuck with them (and I think we are), that does not make
me feel any better about them.

2) Another large group of authors, when using prefixed properties,
do add a fallback to the unprefixed property, even when the specification
isn't final. As they do so, a lot of content accumulates using that
property,
even if no browser implements it unprefixed.

All that content means that even if we later decide to change the name of
the property, the original name has been polluted, and we can't use
it for something else without precautions.

> 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));

Not at all. Under my proposal, we could still have made the changes we
made. Once the "linear-gradient(" syntax had been proposed, nothing would
have prevented webkit to implement it side by side with the
"gradient(linear..." syntax. They supported both syntaxes under a prefix,
they could have supported both syntaxes without a prefix.

Today, there is enough content using the "-webkit-gradient(linear..."
syntax that webkit vendors have decided to never drop it, and other
vendors are considering supporting it was well in addition to the standard
syntax.

Actually, I think there are chances that we would be less stuck with
'gradient' than we are with '-webkit-gradient'. Today, a fair amount of
authors write the following:

background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0, black), color-stop(1.0, white));
background-image: -moz-linear-gradient(to bottom, black, white);
background-image: -ms-linear-gradient(to bottom, black, white);

Notice that they don't include -webkit-linear-gradient, since they already
provide something that works under webkit. They also don't always provide
unprefixed linear-gradient. This reinforces Apple and Google's position
that they can never drop the -webkit-gradient syntax.

With my proposal, authors could have written this:

background-image: gradient(linear, left top, left bottom, color-stop(0, black), color-stop(1.0, white));
background-image: linear-gradient(to bottom, black, white);

Under that scenario, Apple and Google *can* drop the gradient syntax,
since the linear-gradient syntax also applies to them. Maybe they still
wouldn't, due to sites that only use the first syntax without any fall
back, but their case would be weakened.


If you look at properties for which we have not changed the name, the
current prefixing policy actually causes more pollution. Because a non
negligible number of authors
have written (and continue to write) -webkit-border-radius withouth
fallback to border-radius, webkit will support the -webkit-border-syntax
forever, and others vendors may feel they have to as well. With the
proposal I defend, this would not happen.

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

Apple and Google don't merely keep them for way too long, they publicly
stated they would never drop some properties.

There is no direct benefit for Apple and Google to drop their prefixes,
and some benefit in keeping them: don't break sites that used to work,
make life harder for the competition.

As far as I know, Opera has been the best at dropping prefixed properties
when we introduce the unprefixed ones, as we do it instantly, while even
Mozilla keeps them for quite a while. That hasn't shielded us from the
pain caused by other vendors or authors behaving poorly.

A policy that harms most strongly those who follow it best is in my mind
a bad policy.

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

Authors ought to update their sites, but they don't. And when they don't,
they don't suffer from it. Users of other browsers (and by consequence,
other browser vendors) do. Authors use the simplest thing available
to them to provide their clients with the features they want on the
browsers targeted, and we can't really expect them to behave
differently.

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

CSS as a language is successful, and we have a prefixing policy. I am
far from sure that the former is a consequence of the later.CSS might
very well be successful despite prefixing.

The CSS working group is successful because you and Daniel have done
a great job of making it a space where fruitful discussions can happen,
and because vendors are interested in cooperating. Both these points
remain true with or without prefixes, and prefixes would not save
us if vendors did not want to cooperate, or had no good space to do so.

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

The forward compatible parsing rules and fallbacks of CSS give us the
flexibility we need to experiment, without having to involve prefixes.

Due to prefixes as we currently use them, even successful experiments
(whether successful on first try or after heavy modification) need to
be migrated away from prefixes, onto the standard syntax, and this is
proving painful.

  - Florian

Received on Friday, 18 May 2012 17:45:20 UTC