I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

-alpha- and -beta-

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 -alpha- prefix.

Before delving into the pros and cons of -beta-, let’s briefly restate the problem:

1. It’s clearly in the interest of IE, Firefox, and Opera to start supporting -webkit- prefixes, and they will do so.
2. Currently the onus of maintaining the system is laid on web developers, and they’re just not going to do that. The movement to make them aware of the problem is going to fail because it’s just too much work and doesn’t solve the real problems. It only addresses the symptoms.
3. Thus the current vendor prefix system is dead.
4. Still, there should be a way of creating a “beta namespace” for experimental CSS features.
5. Thus, we need proposals for a new system. Unfortunately, except for the -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.

-beta- pros and cons

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.

-alpha-

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:

1. A browser wants to implement a new CSS feature, and creates -alpha-coolfeature: 100% for web developers to evaluate it.
2. Another browser agrees with the basic idea but disagrees with the syntax and decides on -alpha-coolfeature: 1.0.
3. These differences of opinion are quite allowed in this stage, and web developers will not be able to use coolfeature cross-browser with a single line of CSS. It’s an alpha feature, after all.
4. After some discussion and an initial submission to W3C, let’s assume everbody agrees the feature is a good idea, and the first browser agrees that 1.0 is better than 100%. Now we’re ready to move to the next stage.
5. All browsers implement -beta-coolfeature: 1.0, and make -alpha-coolfeature an 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.
   Update: After thinking about it I'm not so sure any more the -alpha- should stick around. Maybe it's better to remove it entirely, so that the temporary nature of alpha declarations is stressed.
6. By this time, web developers will be certain that the -beta-coolfeature: 1.0 syntax is one for the ages, and may implement it in production code without fear of future breakage.
7. Still, in this stage there are likely to be some differences in implementation. This is comparable to the current situation where -webkit-coolfeature may differ slightly from -moz-coolfeature.
8. Once the standardisation process has moved on and all browser differences are resolved, the browsers implement coolfeature: 1.0 and -beta-coolfeature becomes 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 -alpha- to -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 -alpha-/-beta- system that solves most of the objections that were brought in against a pure -beta- system.

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.