W3C home > Mailing lists > Public > www-tag@w3.org > May 2012

Re: W3C discussion of CSS prefixes

From: Florian Rivoal <florianr@opera.com>
Date: Fri, 25 May 2012 18:03:19 +0200
To: "Linss, Peter" <peter.linss@hp.com>
Cc: "Larry Masinter" <masinter@adobe.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <op.wevf7tvh4p7avi@localhost.localdomain>
On Sat, 19 May 2012 03:37:23 +0200, Linss, Peter <peter.linss@hp.com>  

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

Because it is considered a best practice for authors to include the
unprefixed property alongside the prefixed one, in anticipation of
what it will probably mean, there is a lot of content out there
that uses the old syntax and semantics, unprefixed.

Changing the semantics without changing the syntax is dangerous using
the current prefixed policy because of that. The WG may agree that
different semantics under the same syntax are an improvement, write it
into the spec, write TCs, go to CR, and all is well until browsers
actually try to support the new semantics with the unprefixed property,
and discover that so many websites break that they don't want to do it
after all. When that happens, we're in a problematic situation.

If we had been working unprefixed from the start, it would be different.
If the semantic change would have broken so few web sites or affected
websites so slightly that vendors would have been ok with the breakage,
we could still have done the change. But if not, we'd have feedback
much earlier about the fact that this change "breaks the web". Maybe
we'd still want to make the change despite the breakage if it was
felt important enough, but we'd make that choice consciously.

And because of the current "best practice" of including the unprefixed
variant, note that the potential breakage isn't caused by the system
I am proposing. It is merely noticed earlier.

Whether it is bad for authors to behave that way is kind of irrelevant,
since they do it anyway, and we have little chance to get them to

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

It will drop, yes, but I wouldn't be so sure about dropping to zero as
long as the vendor in question is in a dominant position in some markets
or in mindshare.

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

Yes, the WG has done a fantastic job at reassessing its priorities lately,
and that's much appreciated. It is a great step in the right direction.

But standardization speed alone can't solve that problem, due to the time
it take for new browsers to be released and adopted by users. Even
instantaneous wouldn't cut it.

Say Apple introduces -webkit-foo in a new version safari for iPhone, and  
that we somehow get it from First Draft to CR within a week. It would  
still not be available unprefixed on iPhone until the next version of  
safari, which has a release cycle of about 1 major version per year. Old  
iPhones might not be eligible for the upgrade, so we'd have to wait for  
users to upgrade to a newer device. This easily adds up to two years  
without unprefixed support for a large part of the iPhone userbase.

Even if magically fast standardization, we'd still be dealing with a lack  
of support across the board for unprefixed properties for multiple years.

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

Authors do that because it is the behavior with the strongest intensives.
Doing this means that their site might break once browsers start
supporting the unprefixed version, if the spec has changed in a way
that breaks what they wrote. But not doing this means that their
site WILL break once prefixed are dropped, no matter what.

Given the choice of may break vs will break, authors will pick the
first. The only way to get them not to do that is to promise that
prefixed version will never be dropped. And I don't think we want to
do that.

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

Yes, we did make that change, although I disagree it was an important
change. I believe that both Microsoft and Opera now regret having been
in favor of it.

But since nobody supports unprefixed gradients yet, we still don't know
if this change will actually be ok. If it breaks many sites or important
sites when we try to introduce unprefixed gradients, we might find
out that it breaks too many sites. If that's not the case,
we would have been able to make the change without prefixes as well.
If that's the case, we won't know if it would have been possible
to do it when we decided to, but became a web-breaker since,
or if it was already then.

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

Gradients are actually often used as the background of white text.
Remove the gradient, and you have white text on white background.
That's quite bad. Yes, the authors should have included a fallback,
but often enough, it's lacking.

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

Fair enough, that's a weakness. Experimentation may show that older or non  
standard version have worse interoperability, and I suppose that  
evangelists could help, it is easier to teach people the right way when  
there is one. But I accept that this is not as easy as now for the people  
who care about doing the right thing to notice what the right thing is.

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

The problem is that by leaving the pain on browser vendors and their users,
we're harming the competitivity of these browsers. By how much is hard to
tell, but the game is tough enough without that. That matters beyond
the bottom line of the affected vendors, because diversity is necessary
for the health of the ecosystem. The more we lean towards a monopoly
or mono-culture situation, the higher the chance that de facto standards
will take over de jure ones.

The current system has somewhat of a feedback loop, giving an advantage to
the already dominant player when there is one, and that's unhealthy.

  - Florian
Received on Friday, 25 May 2012 16:04:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:15 UTC