How the World Could Solve the Vendor Prefix Problem in One Month
Stop trying to solve more than one problem in one go, it won’t work. Proposals for the solution
to vendor prefixes have tried to solve additional problems with vendor prefixes (that is, vendor behaviour &
spec change) by adding more complexity, ‘features’ and meaning to prefixes. Stop making things complicated.
Let’s solve one thing, simply, and right now.
I am asking you, browser vendors, to add “-x” as an alias to your vendor prefix in your web browser. That means
that any instance of -x-feature in the CSS will be treated as -webkit-feature in WebKit,
-moz-feature in Gecko, -o-feature in Opera and so on and so-forth.
Why does this solve the vendor prefix problem?
1. Incomplete Features Are Still Incomplete
It’s good practice to always include the un-prefixed declaration at the bottom of a list of vendor
But that relies upon waiting until that feature becomes unprefixed and does nothing to do away with the multiple
list of vendor prefixes until that time.
That reduces the repetition whilst each browser still sees its own feature (-webkit,
2. Vendors Will Be Vendors and That Will Not Change
You cannot threaten, cajole or otherwise incite Apple (or any vendor) to stop being a massively successful company
that will do what it damn well likes.
Vendor prefixes are necessary. There are tons of internal features of different engines that are never
going to be standardised because they are not designed to be exposed to the web or are used in producing the browser
UI or are there for just plain old competition. Standards take time and companies have to ship software.
We can’t stop Apple being Apple, and we shouldn’t try stop lazy developers being lazy developers through syntax.
That is an education problem that has to be solved at a level much higher than syntax. -x is
incredibly lazy—for vendors and developers alike—but it’s lazy and good, rather than lazy and
bad like vendor-specific prefixes.
-x will succeed because it’s lazy in a copy-paste web development world and not busy trying to hit
vendors or developers over the head with a shame stick, or trying to educate the world about best-practices all
within a prefix.
Imagine that in order for HTML5 to be adopted, developers had to update every HTML4 page out there? That’s what
vendor prefixes are, in-effect, requiring. -x- is like the HTML5 doctype. Old code doesn’t have to
change, compatibility goes both ways, we code for the future and the future supports us.
3. Specs Change, Browsers Differ
The -alpha, -beta proposal nonsense doesn’t work because it tries to imbue spec /
standardisation ideas in the I-don’t-care-about-this-crap-copy-paste web developer world where old code doesn’t
get updated unless it breaks horribly.
If you are using any vendor prefixed features then they might break in the future. That is reality and you
can’t (and shouldn’t) try and change vendor prefixes to solve that problem.
Different vendor prefixes don’t work because it assumes that every vendor implementation of a new feature will
be—by deafult—incompatible. That means that every time a vendor adds support for a feature that matches another
vendor, you have to fix your code even when it’s working. -x works because it assumes that
vendor implementations will be the same, unless they are different. You only change your code when it
breaks. With -x, when a vendor adds support for a feature, you get it for free without having to
rewrite the whole damn ’Web.
Let’s imagine this code currently only works in WebKit because only it supports that feature:
And then Mozilla come along and say it should be done a different way. You can just override your code:
You Can Do It, and You Can Do It Now
Mozilla, Apple, Google, Microsoft. You could all implement this small change very easily. You only have to alias
-x to your vendor prefix. It is not asking much. There’s no standardisation involved, there’s no
spec (or “alias -x to your vendor prefix” is it), you don’t even have to arrange a meeting with
Apple and Microsoft both have browsers in beta (Safari 6 and IE10). Including this tiny change would open the flood
gates to developer support. Google can ship the change in 24 hours with Chrome’s update mechanism. Mozilla could
ship it officially in 6 weeks. There is little holding back any of you.
Here is the gauntlet I am throwing down to solve the problem of vendor prefixes:
Announce, or ship—officially, or as a development build—support for -x within one
Month’s time (July 13th 2012).
I believe that to be quite doable, and I hope to hear from you soon.