All posts tagged ‘Prefixes’

File Under: CSS

‘Vendor Tokens’ Offer Another Way Out of the CSS Prefix Mess


CSS expert Eric Meyer thinks that a new proposal, CSS Vendor Tokens, might offer a way out of the CSS vendor prefixes mess.

CSS vendor prefixes were designed to help web developers by providing a way to target CSS rules to specific browsers and use proposed standards before they were finalized. Alas, while they have helped, they’ve also hurt the web.

The W3C’s CSS Working Group is currently in the process of trying to fix some of the problems. We’ve covered one proposed solution from Florian Rivoal, which would make vendor prefixes into aliases and ensure that when a browser implements a new CSS feature, it will work both prefixed and unprefixed.

Another proposal that Meyer wrote to tell us about comes from François Remy, who proposes what he calls Vendor Tokens. “I propose we use unprefixed properties from start,” writes Remy in a message to the www-style mailing list, “but with a token explaining which version of the property we built our CSS for.”

Essentially what Remy proposes is to use a flag much like !important, but to signal which version of the CSS property the rule is aimed at. The advantage is that instead of targeting browsers directly, you’re targeting a draft version of the spec.

Here’s Remy’s example of the syntax:

selector {
    border-radius: 1em !webkit-draft;

It’s a bit less typing than the current method, which would require four lines to convey the same information and, as Meyer suggests, dropping the -draft would simplify things even more. But more important than a simpler syntax is that, as Remy explains it: “any browser which is not webkit but implemented border-radius in a way that is compatible with the ‘webkit draft’ can support the declaration.” That’s a little different than vendor prefixes. With Remy’s proposal other browsers wouldn’t need to impersonate webkit, “they just acknowledge they support one specific property the way the webkit draft defines it.”

So a more full-featured declaration might look like this:

selector {
    border-radius: 1em !webkit-draft !moz-draft !o-draft;

Remy also includes a way to handle scenarios where Apple’s version of WebKit might differ from Google’s or even account for differences in versions of the spec.

As Remy admits, there are some drawbacks to this approach, and the syntax isn’t the cleanest we’ve seen, but as Meyer writes, “it feels cleaner than trying to do the same thing with prefixes.”

It will likely be some time before the CSS Working Group makes a decision on what, if anything, to do about vendor prefixes. If you’re interested in keeping up with the discussion on this and other proposals keep an eye on the www-style mailing list.

File Under: CSS, Web Standards

New Proposal Could End the CSS Prefix Madness

Photo: Ariel Zambelich/

The W3C continues to wrestle with the problems CSS vendor prefixes are causing the web. While they’re useful for web developers, prefixed CSS rules as they are currently known may be causing more problems than they solve. Now W3C member Florian Rivoal has proposed a new solution to the prefixing problem.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way.

Rivoal blames the prefix policy itself, writing, “I believe the current prefixing policy is hurting more than it helps, and that the problems are fundamental to the policy itself, rather than something that can be blamed on various parties for not following it correctly.”

The result is that the web is now in a situation where browsers are planning to start supporting other browser’s prefixes, which just might defeat the entire point of having web standards.

Rivoal’s proposal would change the way prefixes currently work and would solve some, though probably not all of the problems. Here’s Rivoal’s full proposal:

When a browser vendor implements a new CSS feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

If a large amount of content accumulates using a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

The biggest win for web developers — should Rivoal’s proposal be implemented — is that it greatly simplifies the process of trying new features. It would give developers the tools they need to work around individual browser quirks with new features, but is less likely to lead to a situation like today, where WebKit-only CSS rules litter the web.

Another nice benefit of Rivoal’s approach is that it solves the Opera dilemma — that no one is using prefixes for less well-known browsers. “No browser, however new or obscure, would have the problem of being excluded,” writes Rivoal, “authors might not test in it, but if the browser does a good enough job of implementing the property, sites will render as intended.”

Obviously this proposal is just that, but there’s already an extensive dialog on The W3C’s www-style mailing list and it appears that most members are supportive, though some have expressed reservations and possible problems. Mozilla’s Henri Sivonen does a nice job of addressing many potential issues and shortcomings in a very long, thorough post to the mailing list.

It will likely be some time before any changes are made to the way vendor prefixes are handled, and of course none of this solves the problem that’s already on the web today. But, hopefully, with a few changes to the way prefixes work, the web can avoid the WebKit-only problem in the future.

File Under: CSS

Advice From the CSS Guru: Embrace Prefixes


Sisyphus, by Max Klinger. The four ladies up top are named Gecko, WebKit, Trident and Presto.

Vendor-specific CSS prefixes have been popping up in all the shiny and fancy CSS 3 demos of late. Microsoft IE 9, Firefox and Safari have all been using them to show off their latest CSS tricks, and you’ve probably already formed an opinion about them.

Web purists scoff at prefixes, since they add to the amount of coding and testing required just to get something to show up consistently across browsers. Repetition and bloat aren’t welcome in this camp. But those who live on the bleeding edge see them in a different light.

In his latest piece for A List Apart, noted CSS scholar Eric Meyer argues that vendor-specific prefixes should be welcomed, not reviled: “We ought to praise vendors for using prefixes, and indeed encourage them to continue,” he writes.

Meyer’s argument is simple. Coding a stack of prefixes into your CSS is not ideal, but it’s better than the alternative of using inconsistent CSS hacks or having to sniff for user agents to serve up totally different styles to different browsers.

He also argues that, “prefixes should become a central part of the CSS standardization process… I believe that prefixes can actually accelerate the advancement and refinement of CSS.”

And it makes sense. Consider the author working with some brand new CSS property. At this point in its young life, all of the browsers are implementing the property, but all are doing so differently. The author can use the property — with prefixes — and gain the utility of whatever magic that CSS property is supplying without having to worry about their pages breaking in such-and-such browser.

These temporary hacks dwindle over time, Meyer writes.

As time goes on and implementations become consistent, browsers will drop the prefixes. From then on, authors will be able to write one line for border-radius instead of six-plus lines of CSS. Without them, we’re just waiting for the next botched implementation that forces us to support it through hacks for years upon years.

Definitely check out the whole article. It draws some interesting conclusions. Meanwhile, how do you feel about prefixing in CSS? Does it bother you, or do you agree with Eric that the practice will only make everything more interoperable in the future?

See Also: