Re: W3C discussion of CSS prefixes

On May 18, 2012, at 9:51 AM, Florian Rivoal wrote:

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

I never said that the *content* of the web isn't getting "polluted" with experimental content, however, the standard CSS language itself has been protected by prefixes very effectively. (And I use the term "polluted" extremely loosely here.)

With the current prefix policy in place, the WG is free to change both the name and behavior of any proposed feature right up until the the spec enters CR and/or the WG agrees that the feature is now stable. This is an important power that the WG has, and we have used it to good effect.


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

I accept that there is a lot of content using -webkit- prefixes today, and that a large amount of it will never be updated, such is the nature of web authors. However, once the un-prefixed version of those features is available, the percentage of prefixed content will drop off over time and eventually the amount of new content using those prefixes will be zero.

The best way to alleviate that situation is for the WG to move faster for those features gaining the most traction. In one way, the pain felt here is a good thing, because it puts pressure on the WG to shift its priorities (which we have done).

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

Yes, authors do that, because they have been taught to, that was a mistake. We need to teach them otherwise. No author should be putting an un-prefixed identifier into a production stylesheet before the feature is declared stable by the WG.

Note though that the WG has much more freedom to change the syntax or behavior of those features because generally, when an author does that, they also have the full range of prefixed versions. If the un-prefixed feature doesn't parse, their page doesn't break as long as the browser still supports the prefixed version.

Not an ideal situation, but less painful than if _every_ experimental property was un-prefixed.

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

No, we could have made _some_ of the changes we made, but not all of them.

Your proposal only works when all changes to the features are made in such a way that the old version doesn't parse anymore. This is doable (mostly) when when syntax changes. What it doesn't let us do is change the _behavior_ of a feature without also changing the syntax in an incompatible way.

If you recall, at one point we changed the direction that angular units took effect in gradients. And that was an important change. How could we have done that under your proposal?

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

"Never" on the internet is only usually a few years… I'd wager good money that WebKit drops support for the prefixed version of gradients before too long. As you're well aware, maintaining code to support legacy content is painful. Once the percentage of content relying on the prefixed version drops to an acceptable level, support for the prefix will go away.

Also, some kinds of prefixed properties are much easier to break than others. If a gradient goes away, generally the site won't break.

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

And under this scenario, how can a novice author, by simply looking at that stylesheet, know which variant of the feature is the standard method and which is the one put in there for legacy browsers?

We all know that very few authors read specs, mostly they learn by example. Under your proposal there's no way for authors to learn the "right way" by example.

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

As I said in another post, once a feature is stabilized and available un-prefixed, I'm OK with browsers supporting each other's vendor prefixes under certain conditions. Its not ideal, but it answers some of that pain.

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

Dropping support for prefixed identifiers once the un-prefixed version is available is, to the best of my recollection, an informal policy the WG encourages. I don't recall us ever saying that an implementation MUST drop prefixes, at best they SHOULD. When to drop and the level of 'harm' a vendor takes by doing so has always been up to the vendor.

We all know that if all vendors encouraged authors to update their content as the specs mature "the world would be a better place"™, but we all have to deal with the world as it is.

The policy of trying to improve the web is, in my mind, a good 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.

Yes, when sites break the user suffers first, but the authors suffer too if they care about their hit counts, just indirectly. Any author coding a site using proprietary features has no right to expect their site to work in any browser other than the one they targeted, and that includes the version of the browser they targeted. When they do so, the author is, by definition, creating a non-standard site, and IMO they fall somewhat outside the scope of a standards body.

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

Yes, authors will behave in a way that they perceive to be in their best interest. They won't always be right in that call. Where we can, we should teach them better. Forcing them to update their content is a good way to teach them :-)

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

I never said that the CSS language, or the WG was successful because of prefixes, I said the prefixes themselves were successful at doing what they were designed to do. I don't believe you can argue that point.

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

Only if changes are made in such a way as to be incompatible at parse time with the previous behavior. This allows some forms of syntax changes, but does not allow functional changes that don't impact syntax.

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

The high level problem here is that we're dealing with the intersection of two fundamentally opposing forces. One force is browsers going off and experimenting and innovating on their own, which is a good thing. The other force is getting browsers to come together and work just like their competition, which is also a good thing.

There is absolutely no way that I can conceive of for these two forces to meet and there not be pain somewhere. We can try to mitigate the pain, and we can certainly send the pain into different directions, but we can never eliminate it completely. If you can come up with a solution that really eliminates the pain, I'd love to hear it, but I haven't seen one yet.

Your proposal merely shifts the pain back into the evolution of the CSS language itself. While this may seem like a better solution to you (and I accept that it would help Opera over the short term), I believe it would cause a lot more long term damage.

Received on Saturday, 19 May 2012 01:38:31 UTC