Proposition to change the prefixing policy

Warning: long mail. If you want to skip the rationale, and just want the
technical proposal, jump down to "==== Proposal ===="

==== Background ====

I believe the current prefixing policy is hurting more than it helps, and
that the problems are fundamental to the policy itself, rather than
something that can be blamed on various parties for not following it
correctly.

While the current policy is very clear and simple to follow for browser
vendors, the same isn't true at all for authors. Unless the simplest
and most obvious way to use something is also the right way, it
is bound to be misused. Here we can't even agree on what the right
way is.

Some have argued that authors should not use prefixed properties in
production sites. I disagree that this is desirable. The web is
significantly more competitive as a medium when work-in-progress features
are used, especially given how long it takes to properly standardize
something. And this widespread usage also provides important feedback
to the designers of the spec.

But if authors are to use prefixes, how should they use them? Some members
of the working group believe that authors should not include the
unprefixed property alongside the prefixed ones because it restricts the
WG's ability to make improvements that are incompatible with early
proposals, defeating one of declared goal of prefixes. On the other hand,
a great number of web pages are written during one-time projects, and then
used for many years without maintenance. Writing such pages without
including the unprefixed property either guarantees that the page will
eventually break, or that vendors will be unable to remove support for the
prefixed property even when they support the unprefixed one.

Similarly, including the prefix of browsers who have yet to ship an
implementation of a new property discourages them from experimenting with
different behaviors, as doing so would break the content which was written
in anticipation that the behavior would be similar. But not including the
prefix means the page, unless maintained, will never work in that browser.

On top of that, there is the obvious point, often raised by authors, that
the current system is painfully verbose and tedious to maintain, which
sometimes causes them to not include the prefixes that would be necessary
to support browsers with a smaller market share.

The web is meant to be a universal medium, agnostic in terms of device or
UA. Of course, testing in several browsers is needed to iron out bugs.
But when authors have to write for one browser, then port to a few other
selected ones, something is wrong.

All in all, there is no simple right way for authors to use prefixes as
they currently are.

==== Proposal ====

When a browser vendor implements a new css feature, it should support it,
 from day 1, both prefixed and unprefixed, the two being aliased. If a
style sheet contains both prefixed and unprefixed, the last one wins,
according to the cascade.

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.

If a large amount of content accumulates using the a particular vendor
prefix to work around an issue with the early implementation in that
browser, the vendor could decide to freeze the behavior of the prefixed
property while continuing to improve the unprefixed one.

==== Benefits ====

The excessive verbosity and tediousness that authors complain about
today goes away, and unlike the current system, there is no question
about how authors are expected to use this, reducing confusion and
grief. At the same time, it gives them the tools they need to
work around the inconsistencies that are to be expected in early
implementations of work-in-progress specs.

No browser, however new or obscure, would have the problem of being
excluded. Authors might not test in it, but if the browser does
a good enough job of implementing the property, sites will render as
intended.

This approach also makes it significantly easier for vendors to drop
support for the prefixed variant once they pass the test suite of a
CR level spec, since uses of the prefixed variant were to work around
bugs it no longer has.

Less importantly, under the current approach, browsers should use
prefixes until they pass the official test suite, but the test suite is
writen without prefixes, so you either need a special version of the test
suite or a special version of the browser to check compliance. With my
proposal, there is no such problem.

Of course, this scheme means that a large body of content may accumulate
in the wild before a property is fully standardized, but I don't think
this would have any significant negative impact on standardization.

First, there are a number of areas where the specs are far ahead
of implementations and real word usage. Work on such specs
would not be impacted.

Even when there are implementations, if they are still too immature
for authors to use in practice, nothing will prevent the WG from
changing the features for the better.

In the cases where implementations and real world usage are ahead of the
spec, then yes, it would limit the ability of the WG to make incompatible
changes. But this isn't necessarily bad. Even with the current prefix
system in place, the WG should be hesitant to change massively popular
features. These changes are costly no matter what, and should only be
done when there are very good reasons.

This doesn't mean that the WG would just be a rubber stand body validating
de-facto standards. It takes a lot of effort to go from 'it kinda works
well enough to be used' to REC level quality, and the CSS WG would still
be the place of choice for that work to happen.


I hope we will get the chance to discuss this during the upcoming face
to face.

Regards,

    - Florian

Received on Friday, 4 May 2012 17:26:47 UTC