Deutsche VersionCSS vendor prefixes vs OpenGL
So [Opera is planning to parse -webkit- prefixes in CSS][operaplan], and everybody is crying out. From a practical point of view, though, it is a very good idea. Right now, CSS developers that want to take advantage of experimental properties have to write the same code up to four times with different prefixes (-webkit-, -moz-, -ms-, -o-). That is a horrible, horrible idea. It is made worse by the fact that CSS knows no variables or constant definitions, so you have to change all values in all four places, but that’s another issue.
From a more idealistic point of view, however, this is bad: The prefixed properties are supposed to be experimental only. By “blessing” the Webkit versions, Opera is encouraging bad coding practices, and if Opera isn’t 100% compatible with Webkit, then chaos will ensue.
There is an argument that people should simply not use properties that have vendor-specific prefixes in production. But that is unrealistic. The properties are there to be used. If not, browser developers would make it a lot harder to get access to them (for example by supporting them only in nightly builds).
OpenGL extensions
It is interesting to compare this to the situation with OpenGL, another technology where development is driven almost entirely by vendor-specific extensions. OpenGL is a graphics library specification. If vendors (those include mostly the graphics card manufacturers and Apple) wants to add functionality, they can create an extension. All the specifications have a vendor-specific tag in the names of the functions and constants they use, e.g. NV for Nvidia, AMD, ATI, APPLE or INTEL. If a vendor wants to implement something new, all they have to do is write a specification for the extension and then implement it, using their own names[^1].
[^1]: Because all OpenGL constants share one number space (don’t ask why. OpenGL is weird), it is actually necessary to get values for the constants assigned from the Architecture Review Board, but this is a formal step only.
The interesting part is that OpenGL also has two special prefixes: EXT for extensions shared by several vendors, and ARB for extensions that have been approved by the Architecture Review Board and thus become official. ARB extensions often become a core feature in the next OpenGL version. A good example for that is the [rectangle texture extension][rect]. It was created by Nvidia as GL_NV_texture_rectangle. Because it was useful, other vendors implemented it as well, and thus it was moved to GL_EXT_texture_rectangle. Finally, it arrived as GL_ARB_texture_rectangle. As of OpenGL 2.1, it is part of the core OpenGL specification.[^2] All of this is fully downwards compatible, because while the names have changed, the specification hasn’t, and it is trivial for one implementation to support all historical and new names.
[^2]: As of OpenGL 3.0, I wouldn’t use it anymore. Non-power-of-2 2D textures solve the same problem, but have far fewer limitations. But that is a different issue.
Different vendors can implement different extensions that do the same thing, but are incompatible. The final ARB specification can be different again. As an example, for synchronization, you can choose between [GL_APPLE_fence][a_fence], [GL_NV_fence][nv_fence] or the standardized, but very different, [GL_ARB_sync][arb_sync].
Note that the move to EXT and ARB does not have to happen: Any vendor can implement anyone else’s extension, based on the official specification. It is just very common to move it to EXT.
In CSS
How can this be adapted to CSS? First of all, there should be a shared experimental prefix. I support -ext-, because of the OpenGL background, but [others prefer -beta-][betaprefix], which may be a bit more obvious. The second important part is that anyone who has an extension has to write a specification for it, so that other browsers can implement it as well, if they choose to. The specification for -beta- can then state that it is identical to one or more previous vendor-specific extensions.
The end result is very similar to the [Alpha-Beta system proposed][alphabeta], but keeps the vendor-specific syntax for experimentation, and offers a way to specifically say that a beta version is compatible with a browser-specific one.
What do you think?
Written on April 25th, 2012 at 10:00 pm
