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