Peter-Paul Koch drops a PPK-bomb on CSS vendor prefixes, the latest post in what seems to be a series of rants which get everyone thinking and talking: not necessarily agreeing. But if you know PPK, then you know that’s probably not the point.
You should read the post. Then form an opinion. Mine is that vendor prefixes are no fun and quite annoying, but a necessary evil. At least for now. There’s no need for me to go into why, as Jonathan Snook makes the point well.
My biggest problem with vendor prefixes is the repetition (read: not the amount of typing), and the fact that I’ll one day need (okay, want) to go back and clean prefixed rules up once they’re no longer necessary or when the implementations change, which they can. I just want a clean style sheet.
A few workarounds, or deal-withs, were mentioned in the comments of the aforementioned posts:
- A single “beta” prefix
- CSS preprocessors
- A separate style sheet
I like the last option the most, hat tip to Bridget Stewart for beating me to it. A separate style sheet fits my current practice of giving each element of design language its own file (I know about the performance implications, but there are plenty of solutions to that). So a generic group of style sheets for a given website might look like this:
- layout.css
- type.css
- color-img.css
- vendor.css
- ie[x].css
This is clean. Non-prefixed properties are entered into the normal style sheets, and will (hopefully) be ignored by browsers which don’t understand them. Prefixed properties are placed in vendor.css. And what I would really love is for CSS3, Please! to generate vendor.css for me (That was a hint, guys). Sure, there’s the risk of the spec changing, so it’s up to the designer/developer to be wise in deciding which things should be specified without prefix in the normal style sheets.
Why not the other two?
To be honest, something like -beta- might not be a bad idea, but as of yet, the fact that vendor prefixes are browser-specific is the only useful thing about them. A universal prefix is just that, universal, which could potentially introduce the same problems we would have with no prefixes at all.
I’m not a big fan of CSS preprocessors, or at least I haven’t seen one I’ve liked. We’re talking about CSS; it’s not all that hard to deal with. My problem is not with typing things out three or four times. And I don’t need a preprocessor to do that for me, as prefixes and things like rgba fallbacks are easily accomplished in any decent editor through snippets or scripting. And for those without a decent editor, just use something like CSS3, Please!.
How do you cope?
You only need to subscribe to www-style for about a week before realizing it’s going to take more than three people calling “-beta- prefix!” to get browsers to do it. When you dig down deep enough, there are some very, very smart people who have thought a lot about certain things (and admittedly less about others). It would be a good practice to research or ask why something is as it is, and perhaps participating in www-style and submitting ideas.
You could also try vendor.css. If you hate prefixes, at least you’ve gathered them all together in their own little prefix hell.
How do you deal with vendor prefixes?
It’s a personal preference, of course, but I rather dislike the idea of using
vendor.css.By using a separate style sheet for vendor shizzle, you sacrifice maintainability. Not to mention the cost of the additional HTTP request (unless you minify your CSS before deployment).
While I am too have little patience to try new things, I tend not to use properties that are vendor-prefixed. In most cases I’d rather use an old school solution (like using background images for round corners) than implementing various different browser implementations.
When will browsers ever be able to use official standards for these techniques? I don’t know. But what I do know is that it will take a very long time before browsers will drop their prefixed properties that are currently available. The more we use this kind of properties, the longer it will take and the less pressure is on W3C to move on with proposed new standards.
BTW: You talk about “the fact that I’ll one day need (okay, want) to go back and clean prefixed rules up once they’re no longer necessary”. You will never want to do that, because chances are 99% that the css and/or website will be rewritten entirely before or shortly after the definitive standard is released.
@Mathias: I don’t see how this has to be a maintainability problem. Enlighten me if you will. And as I mentioned re performance, there are solutions for that, minifying being one of them. That doesn’t need to keep us from splitting things up.
@Sint: I have to disagree with you: using hacks and workarounds may not hold the web back, but I’m not convinced they’re good for the web either. Nor for you as a developer. I see using these properties as a good thing. We all should be trying these things out and giving feedback whenever we can. Use CSS3. Use HTML5. Just think carefully about what you’re doing.
I fail to see how the use of prefixes affects W3C speed.
Thanks for your comments!
@Stephen: The maintainability problem is that if you ever need to change a declaration, you now have two files to (remember to) edit instead of one. That’s definitely not making things easier.
The performance issue is the following: unless these files are minified and concatenated (I didn’t mention that very clearly in my first comment), the use of
vendor.csscomes at the cost of an extra HTTP request.The way I see it,
vendor.csssimply creates more problems than it solves.An example where it works without vendor prefixes is HTML. The implementations of, say, <video> started out wildly disparate, but eventually converged on what the spec says. For this to work in CSS, we would need a CSS Hixie, and who wants that? I’m glad the CSSWG still operates in a more consensual way. Or at least so it seems from the outside.
Vendor prefixes were meant to be a way of implementing proposals quickly as an experiment, while making it very clear they are volatile. They weren’t meant to stay around for months, and they definitely shouldn’t be supported in a browser once there is a non-prefixed version. Firefox dropped -moz-opacity support fairly quickly, and that’s how it should be, because having to support obsolete experimental versions is a pain. Even more of a pain are all those proposals (over at PPK’s comments) for convoluted per-feature versioning switches. Same for -beta-, it would just extend the lifetime of obsolete syntax. What we need is not versions, but one standard. Features should be standardized or at least declared “pretty stable” faster and in a more granular way.
If you as an author use vendor prefixes, you implicitly agree to live on the edge and update your CSS every time a new browser version comes out. If you don’t want to be a CSS beta tester, better delete everything that starts with a hyphen now.
@Mathias: While I agree with you in principle, there’s still a part of me that just wants to keep things clean and clear. Since I’m a fan of type.css etc. anyway, I’m not afraid of multiple files. Within a multiple-file workflow, it’s very maintainable (and I agree with you on the minify/cat point). In a one-file workflow, it’s not. You say potato, I say po-tah-to, so to speak. I don’t think there are more problems, just different problems.
@Cory: I like beta-testing CSS. If browsers stop supporting a given prefixed property as soon as they officially support the same property without the prefix, that gives me just slightly more incentive to use a separate style sheet for the beta.
Hey Stephen, I’m gonna throw down a POV that’s similar to Mathias’.
The extra HTTP hit is rather costly. (Unless you’re doing custom concat’d css builds and serve them by user agent , which is very caching-unfriendly…)
In my post about conditionally classing the body tag I point out the arguments against breaking up IE rules into their own sheet. In my experience, teams have a hard time dealing with rules for one widget that exist in two totally different locations. I avoid it when possible.
Therefore, I think we should just *deal* with their ugliness. At least the whitespace formatting at css3please makes it all look as good as it can.
Hi Paul,
I know it’s costly (at least that’s we web folk say as of late, since performance is the new black), and I have indeed debated revising my opinion on using multiple files in favor of one larger file, nicely organized. I just haven’t finished my internal performance vs. maintainability debate yet. I still find many advantages to using multiple files, each representing a component of design language. For designers, it can be pretty intuitive. For hardcore developers perhaps less so. For designers like myself, it’s maintainability vs. performance. I respect that this is akin to discussing gun control.
Getting back to vendor prefixes: note that while I find a vendor.css to be the most intriguing of the three ideas expressed in comments of PPK en Snook’s posts, I don’t use it myself. If you and Mathias keep badgering me, then I probably won’t :-)
What about making the browsers accept the vendor-specific as well as the non-prefixed properties from the start and treat them in the same way, but let the vendor-specific variant override the other if there is a difference?
That way, if it so happens that all vendors treat a certain property in the same way, you could abandon the prefixes in your stylesheets without losing compatibility with the first browser versions that tried out the property. And if the syntax happens to be different in for example Firefox, -moz- will let you add the alternative syntax for previous versions.
The way it is now, i will need to add up to 6 variants of the same property, (either by myself or with i.e. a server script, but it needs to be there, cluttering up the code served to visitors) and I will need to do so for years to come. Unless, of course, all browsers that have been installed on computers worldwide in the past few years magically update themselves to the newest, standards-compliant versions when they are released… Somehow, this feels like IE6 all over again.