Re: Unprefixing CSS properties

* Robert O'Callahan wrote:
>One observation is that when browser vendors already agree closely on the
>syntax and semantics of a property, and when Web authors routinely use the
>same property value for multiple engines' prefixed properties and the
>unprefixed property, in public Web content, vendor prefixes are providing
>negligible benefit and incur considerable costs --- or outright harm.

The Working Group would have to publish recommendations on a bi-monthly
basis in order to complete CSS Level 3 within 20 years since the start.
If it cannot advance specification to recommendation status much faster
than it has for the existing CSS Level 3 recommendations, Spock will be
around when the last recommendation is published. Without time travel.

Vendor prefixes are for proprietary features and so long as the features
haven't made it through an appropriate standardization process they re-
main proprietary. If authors have to increasingly rely on proprietary
features, that will hurt everybody sooner or later, regardless of vendor
prefixes. Overdoses of vendor prefixes are supposed to hurt; and you get
to see who is to blame every time you use them. They work as intended.

>I think we can improve the situation in the short term with relatively low
>risk by identifying properties whose specs are not yet in CR, but where the
>spec is considered stable (but for whatever reason not ready to enter CR,
>perhaps because it contains other properties that aren't stable), and
>agreeing to encourage unprefixed implementations of those properties.
>Naturally we still want implementations to be reasonably conformant before
>shipping unprefixed.

So browser vendors would like us to suspend the standards process and
award them emergency powers so in addition to controlling the standards
de-jure by controlling the Working Group and de-facto by controlling
the implementations, they also get to form a cartel that would declare
features a "standard" by decree, all to address a problem they caused;
in addition to the concessions we have already made by allowing browser
vendors to ship features without the Working Group releasing at least a
very rudimentary test suite first. And the only reason for that is be-
cause browser vendors would like to mix features they want to implement
now and features they might consider implementing in the years to come,
in the same specification.

How about we aim instead to have Recommendations for features that are
widely used? You know, so we can make web sites based on standards, and
not some editor's draft or a candidate recommendation that's parked in
the "everybody implements this but nobody's writing test cases" garage?
Set up some sensible errata and revision system so the folks who can't
sleep at night if they can't fiddle with their draft the next day can
find some rest, while allowing the rest of us to have synchronization
points? Synchronization points that provide some mild pressure not to
linger on "well, there is a stable draft and there are some tests some-
where" but rather do what little it takes to push it the last mile?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 17 November 2011 01:26:57 UTC