My article yesterday about the vendor prefix mess garnered quite a few interesting comments, and today I’d like to respond to those that object against my proposal to replace the current system by a universal
-beta- prefix by proposing an additional
Before delving into the pros and cons of
-beta-, let’s briefly restate the problem:
-webkit-prefixes, and they will do so.
-beta-solution I haven’t heard of any yet.
I’m not saying
-beta- is perfect. I am, however, saying, that we need something new. Unfortunately opponents of the
-beta- solution refuse to acknowledge that the situation has changed, and continue to beat the dead horse of getting web developers to solve what’s essentially a W3C problem.
If you don’t like
-beta-, propose something else. We can only make the best choice if we have several alternatives to choose from.
Update: I was directed to this proposal. Although I think it's too complicated (especially the versioning), it's good to see others thinking about alternative systems.
One other point needs to be cleared up before we proceed: the fact that the current system is dead does not mean that the current vendor prefixes should be removed from all browsers. On the contrary: they are still necessary for backward compatibility, and will probably continue to exist forever. Only new experimental CSS declarations should use the new system.
The main advantage of the
-beta- system would be that it puts the onus of maintaining it on the standards bodies and browser vendors instead of web developers. Web developers who want to use an experimental feature just add
-beta-coolfeature to their CSS, and they’re done forever — unless the feature changes (but they run that risk nowadays, too).
Still, there are also disadvantages. Stuart Langridge worded them first and clearest:
if opera adds -beta-ppk: 100% and mozilla adds -beta-ppk: 1.0 then there is no way a dev can write a style sheet that works in both
This is totally true. If two browsers use two different values, your
-beta-coolfeature will work in only one.
My take is: so what? Isn’t this how experimental features are supposed to work?
The underlying assumption is that we as web developers should be able to use all
-beta- features in production code from day 1. Although I admit that this is what’s currently happening, we should wonder whether it’s the desired outcome. Unfortunately I know too little about the history and stated purposes of the current vendor prefixes to answer that question.
Still, the contention that a beta feature is used at your own risk, and without certainty of cross-browser support, doesn’t strike me as entirely unreasonable.
Underlying web developers’ desire to start using beta features is the fact that W3C is so terribly slow in moving features to final specification. This problem is not new, and there’s even something to be said for slow and careful deliberation, but right now the costs of maintaining this system rests squarely on web developers. That, to me, is the true problem.
Then Twitter user Philippe Antoine proposed an additional
-alpha- prefix. After thinking about it for a few seconds I decided that I like it, and that it may solve some of the objections against
-beta-. Essentially, it provides a basic versioning mechanism.
It would work roughly as follows:
-alpha-coolfeature: 100%for web developers to evaluate it.
coolfeaturecross-browser with a single line of CSS. It’s an alpha feature, after all.
-beta-coolfeature: 1.0, and make
-alpha-coolfeaturean alias that points to it. Note that the style sheets that use
-alpha-coolfeature: 100%are going to break now. That is perfectly all right: alpha features cannot be expected to stick around forever.
-alpha-should stick around. Maybe it's better to remove it entirely, so that the temporary nature of alpha declarations is stressed.
-beta-coolfeature: 1.0syntax is one for the ages, and may implement it in production code without fear of future breakage.
-webkit-coolfeaturemay differ slightly from
-beta-coolfeaturebecomes an alias. Breakage of style sheets does not occur, although minor side effects in some browsers are possible, just as they are under today’s vendor prefix system.
Thus the most visible part of the change from
-beta- would be that the syntax stabilises. Browser vendors should also have reached an agreement on the basics of the new feature, but that’s generally less visible.
The best part of this proposal is that it’s pretty easy to explain even to newbies:
-beta- is reasonably safe, while
-alpha- isn’t. If you use
-alpha- you’re totally on your own. If you use
-beta-, on the other hand, you’re in the same situation as with today’s vendor prefixes, and you can safely expect the syntax, at least, not to change any more.
So I modify my proposal to an
-beta- system that solves most of the objections that were brought in against a pure
If you still don’t like it, by all means propose your own system. But please don’t pretend that maintaining the current system is an option. Vendor prefixes are dead, and any further discussion should take that fact into account.
I’m around at the following conferences: