RE: Proposition to change the prefixing policy


[Daniel Glazman:]
> 
> Florian, I think your proposal has one flaw only but that's a pretty big
> one... We introduced prefixes originally to be able to have preview
> implementations potentially differing from the final spec and
> implementations. Prefixes were supposed to allow vendors to start
> implementing, test, discover issues and hence feed the standardization
> process. If preview implementations are aliased without prefix, they will
> be adopted by web authors, and sometimes _widely_. Some browser vendors
> said they just cannot let web sites suddenly become broken when an
> implementation changes following spec changes. That concern remains. If
> property A is implemented prefixed AND unprefixed at date d, and the spec
> for that property changes at date d+1, how will vendors update their
> implementation AND preserve sites implementing date d's draft from
> breakage?
> 
The simple answer is that this already happens today. Different prefixed
implementations support different versions of a draft. For instance,
Gecko's early font-feature-settings implementation requires unquoted 
OpenType tags, Trident's came later and requires them to be quoted per 
the newer spec draft. So you have to feed equivalent values to each engine. 
And this is what prefixed properties are perfect for (vendor prefixing is 
engine sniffing by another name, after all).

A trickier scenario is when the change is behavioral i.e. the semantics
of a value change, or a new set of values are not treated as invalid but
do nothing or something different in the older implementation. Given
established practice of specifying the unprefixed property last this is
worrisome as the newer value would always win. I suppose the workaround 
would be to specify your engine-specific workaround after the prefixed 
version instead so the older engine picks the preferred fallback through 
the cascade. So the pattern would be to declare the unprefixed property 
first, followed by engine-specific overrides if/when testing indicates 
you need any. This of course implies the original prefixed implementation 
of the feature doesn't change over time or stays backward-compatible; this 
is already largely true today in my experience.

This brings up a much bigger issue though: whether, why and how the WG 
should change something that is widely used.

If we do our job well, the differences between the earlier implementations
and the final standard will either be minimal (border-radius) or have very 
limited impact due to lack of use on the web (flexbox). In cases where a 
feature is widely used and the WG would like to make a change then I think, 
on principle, that making breaking changes much harder for the WG is a feature,
not a bug. When a feature does achieve wide traction the editor(s) and the 
group should have very strong incentives to find compatible ways to address 
a new issue. 

Note that I do agree it is good for the web to ensure the standardization 
process is insulated from the whim of any single vendor. I'm not as sure it 
is good for the web when the standardization process is sufficiently insulated 
from the current state of web content that it can force breaking cosmetic 
changes on a popular feature at the 11th hour*. Once a feature is widely used, 
changing it will have a very real cost the people who build the web. 
That the current process makes such changes virtually free to the WG is, imo, 
the bigger flaw here. 

Some will argue the long-term gains of, for instance, better consistency or 
usability - as they see it - are far more important than the short-term pain 
on early adopters. That may be a defensible position when looking at a single 
module. When developers who learned gradients and flexbox in the past year 
already have to re-learn their syntax or naming and update their content 
accordingly - as our Win8 app developers are doing today - I still wonder how 
sustainable or beneficial this is given all the promising modules we have going on. 

Overall, I don't think raising the bar for change based on a feature's success is a 
crazy idea though agreeing on what 'successful' means may not be easy. 

While I suspect it may be too time-consuming, I wonder if it would be helpful 
to do a what-if against a couple of recent modules: what if we had followed 
Florian's proposal and unprefixed flexbox or gradients or transitions at a much
earlier point in time? What changes would have been hard or impossible to make in 
a backward-compatible manner? What solutions would we have come up with instead?
How good/bad would the result be? 


*: Yes, I am thinking of gradients. Yes, I agreed to most of these changes at the 
time. Yes, I now believe I was mistaken. Yes, we shouldn't extrapolate from just 
one recent case. Still, the process explicitly allowed and enabled these changes 
to happen. I see no reason to believe this can't happen again beyond the fact that
some of us acquired a strong distaste for such decisions from that experience.

Received on Saturday, 5 May 2012 14:04:02 UTC