As many of us have learned, vendor prefixes are a pain in the butt to maintain, and it’s great that CSS preprocessors and client-side scripts are available to help in this regard.
Although I’ve recommended that the standard property be listed after the vendor-specific lines, for “future-proofing” the code, I’m starting to think that might be bad advice in some circumstances.
Why the Standard Syntax is Included
A typical full-vendor block of CSS3 might look something like this:
.element {
background-color: red;
-webkit-transition: background-color linear .8s;
-moz-transition: background-color linear .8s;
-o-transition: background-color linear .8s;
transition: background-color linear .8s;
}
The thinking is that, once the standard property is supported, any vendor line that gets rendered would be overridden by the standard property. I think this is fine when there is at least one browser supporting the standard syntax, and when the spec is a little further along.
What’s Realistic Here?
When I code something that works using the vendor syntax and has no standard syntax support, I’ve tested it, the client has approved it, and unless the client gives me instructions for changes, that behaviour should not change. The same would be true to some extent with a personal project. I’ve seen the effects and interactions, and I’m happy with them.
So why would I want the standard property eventually to take over and override the feature I’m already happy with? In some cases I think this could be riskier than we think. If the implementation of that feature changes when the browser starts supporting the standard syntax, this might cause the feature to work differently than we had originally intended.
As far as I understand, for legacy reasons, new versions of browsers should support vendor syntax pretty much indefinitely. Even if the vendor syntax stops working in far-future versions, that’s not a big deal. You’re probably ensuring there are fallbacks in IE7/8 anyhow, so it’ll be fine.
When to Omit?
I think at this stage there are a few CSS3 features that could be better off without the standard property included after the vendor prefixes. These might include transforms, transitions, keyframe animations, and gradients. And it may be advisable to take this approach for experimental stuff like regions or flexbox (although it’s unlikely anyone is even attempting these latter ones in a real-world project).
If you choose to do this, here are the minimum criteria that would have to be met:
- The property/feature is supported by all major browsers using vendor syntax
- There is no standard support in any browser
- The specification is still in flux (which is usually true if the above two are true)
To me this is a reasonable solution. After all, if you were to use a CSS feature that’s not in any specification (like WebKit-only reflections or text stroke) you probably wouldn’t include the standard syntax. Thus, all CSS features for which the standard property doesn’t work can be treated similarly.
Even if the standard property gains support in one or two browsers, you’ll still have support in those browsers for the vendor syntax. But in that case, you won’t have the problem of the implementation changing and things not looking/behaving as they did with the vendor lines.
In fact, you could do something like this:
.element {
background-color: red;
-webkit-transition: background-color linear .8s;
-moz-transition: background-color linear .8s;
-o-transition: background-color linear .8s;
/* transition: background-color linear .8s; */ /* uncomment and test */
}
Notice the commented out standard line, with a note. This would remind you to test the code before you actually allowed the standard property to suddenly just take over everything else. Maybe there are better solutions to this, but this is one option.
Thoughts?
As is often the case on this site, this is an informal suggestion that I’m still not totally sold on. More than likely I’ve neglected to consider certain factors. And that’s on top of the fact that I’m not an expert in spec writing or browser implementation processes.
However, even if I’m way off base here, I hope we can get some expert views on record in the comments so developers can make an informed choice on what will work best.
Legacy cannot be trusted.
-moz-background-clipno longer works in Firefox. No matter if used with padding or padding-box value. All of this future proofing is a kind of a bet thanks to the prefixes.And that’s exactly why it would have been good for developers to not include the standard syntax for that one.
If you look at the browser compatibility notes for that property, you’ll see that when
-moz-background-clipwas supported, it was using different syntax for the values. The values it supported were “padding” and “border” instead of “padding-box” and “content-box”. And it had no support for “content-box”.So in that case, If you had included background-clip with the prefix, and no standard property, you’d be fine as long as it degraded gracefully. Also, you would have done this:
So the standard property wouldn’t work in the future anyhow (because the syntax is wrong).
And also look at how the gradient syntax has changed for both radial and linear, so you’d have a similar problem there.
You definitely need that fallback of the default. Using Aurora last week I noticed that -moz-border-radius had been deprecated. So going forward if you didn’t have the default in there you would no longer have rounded corners on your design.
-moz-border-radiusis one of the oldest CSS3 features, so I’m not surprised if that’s true. But there’s nothing wrong with this. Square corners are the fallback, or else Modernizr to fork a hack of some sort. So I wouldn’t see a problem even in that case of leaving out the standard line.“If the implementation of that feature changes when the browser starts supporting the standard syntax, this might cause the feature to work differently than we had originally intended.”
And that’s perfectly normal. They are *experimental* implementations after all. You’re using experimental features whilst wanting a guarantee that it will work forever? In that case don’t use it or wait for the standard implementation to arrive. Or, do what everybody else does…bet on the experimental and standard feature to do the same thing, which in the vast majority of all cases will be true.
I’m not sold on this advise, I think the existing best practice is superior.
You know, thinking about it now, wouldn’t it be easier if we, as web developers, add only the standard property and the vendors work it out to map to their implementations?
This way we would only have one line on the CSS for a certain property and the vendors implement internally applying the prefix.