Unfixed
Published 12 years, 10 months pastRight in the middle of AEA Atlanta — which was awesome, I really must say — there were two announcements that stand to invalidate (or at least greatly alter) portions of the talk I delivered. One, which I believe came out as I was on stage, was the publication of the latest draft of the CSS3 Positioned Layout Module. We’ll see if it triggers change or not; I haven’t read it yet.
The other was the publication of the minutes of the CSS Working Group meeting in Paris, where it was revealed that several vendors are about to support the -webkit- vendor prefix in their own very non-WebKit browsers. Thus, to pick but a single random example, Firefox would throw a drop shadow on a heading whose entire author CSS is h1 {-webkit-box-shadow: 2px 5px 3px gray;}.
As an author, it sounds good as long as you haven’t really thought about it very hard, or if perhaps you have a very weak sense of the history of web standards and browser development. It fits right in with the recurring question, “Why are we screwing around with prefixes when vendors should just implement properties completely correctly, or not at all?” Those idealized end-states always sound great, but years of evidence (and reams upon reams of bug-charting material) indicate it’s an unrealistic approach.
As a vendor, it may be the least bad choice available in an ever-competitive marketplace. After all, if there were a few million sites that you could render as intended if only the authors used your prefix instead of just one, which would you rather: embark on a protracted, massive awareness campaign that would probably be contradicted to death by people with their own axes to grind; or just support the damn prefix and move on with life?
The practical upshot is that browsers “supporting alien CSS vendor prefixes”, as Craig Grannell put it, seriously cripples the whole concept of vendor prefixes. It may well reduce them to outright pointlessness. I am on record as being a fan of vendor prefixes, and furthermore as someone who advocated for the formalization of prefixing as a part of the specification-approval process. Of course I still think I had good ideas, but those ideas are currently being sliced to death on the shoals of reality. Fingers can point all they like, but in the end what matters is what happened, not what should have happened if only we’d been a little smarter, a little more angelic, whatever.
I’ve seen a proposal that vendors agree to only support other prefixes in cases where they are un-prefixing their own support. To continue the previous example, that would mean that when Firefox starts supporting the bare box-shadow, they will also support -webkit-box-shadow (and, one presumes, -ms-box-shadow and -o-box-shadow and so on). That would mitigate the worst of the damage, and it’s probably worth trying. It could well buy us a few years.
Developers are also trying to help repair the damage before it’s too late. Christian Heilmann has launched an effort to get GitHub-based projects updated to stop being WebKit-only, and Aarron Gustafson has published a UNIX command to find all your CSS files containing webkit along with a call to update anything that’s not cross-browser friendly. Others are making similar calls and recommendations. You could use PrefixFree as a quick stopgap while going through the effort of doing manual updates. You could make sure your CSS pre-processor, if that’s how you swing, is set up to do auto-prefixing.
Non-WebKit vendors are in a corner, and we helped put them there. If the proposed prefix change is going to be forestalled, we have to get them out. Doing that will take a lot of time and effort and awareness and, above all, widespread interest in doing the right thing.
Thus my fairly deep pessimism. I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. It’s what we did at Netscape ten years ago, and almost certainly would have done despite any outcry. I don’t mean to denigrate or undermine any of the efforts I mentioned before — they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship. The real question is: how many of your fellow developers come close to that level of commitment?
And I identify that as the real question because it’s the question vendors are asking — must ask — themselves, and the answer serves as the compass for their course.
Comments (21)
I’m wondering if there is room for a -experimental- or -draft- prefix for CSS rules that are identical cross-browser, but aren’t official standards yet. As a developer it’s a bit of a pain to either copy and paste 4 different prefixes, or be forced to use a tool that may mangle your code.
Leave things like -webkit- or -moz- for features that really are limited to those rendering engines.
This whole notion of dropping the self-referential vendor prefix and picking up the others stinks of browsers trying to not “break” the web due to out-of-date code on legacy websites. I think we’ve been down this road before with Explorer and we’ve seen the years of frustration that has caused us as developers.
It should not be the responsibility of the browsers to avoid “breaking” the web due to legacy code hanging around. Doing so will paint all the developers that code responsibly into a corner again.
In the case of border-radius or background gradients, how would that work. There was a lot of churn early on on how -webkit, for example, handled those. Which version would Mozilla pick up on that?
My gut and my mind both say this stinks of a a really bad idea.
To me it doesn’t actually seem like a bad idea, as long as the browser vendors handle it in a responsible way. What the vendor prefixes really let you do is have multiple competing implementations concurrently until the working group decides on one to make official, as well as managing backwards compatibility after a consensus emerges. What’s the problem if a browser vendor decides to support multiple implementations?
So, for example, Webkit’s syntax for gradients is different than Mozilla’s. If Mozilla, in addition to their own -moz- syntax, decided to support the -webkit- syntax it doesn’t seem like it hurts anything. As long as the -moz- syntax takes precedence over the -wekit- syntax in the Mozilla browser, and as long as Mozilla commits to match the Webkit -webkit- behavior as closely as possible, then it seems like developers get the best of both worlds.
For developers who didn’t care to optimize both, the Mozilla browser will look better than nothing. For developers who do care, they can continue to target the Mozilla browser as they do today. If inconsistencies arise between the Mozilla -webkit- implementation and the WebKit -webkit- implementation then it’s Mozilla’s responsibility to try to address those as bug fixes, but they can continue to leave -moz- as is. This means that any change in the behavior of the -webkit- prefixed properties in a Mozilla browser will be to move those properties to more closely match the behavior that the developer actually tested against (it would be crazy for a developer to test only in firefox, but use only the -webkit- property).
What am I missing?
Pingback ::
Eric’s Archived Thoughts: Unfixed - bookmarks
[…] http://meyerweb.com/eric/thoughts/2012/02/09/unfixed/ Posted on: February 9th, 2012 […]
From where I’m standing, this issue and its close cousins always have — and will continue to — revolve around two basic issues:
1. “Oooh! Shiny things!”
This is an oversimplification, but close enough to the reality all the same. When developers take this tack to their non-vanity-slash-non-skills-dev projects, they’re doing an awful disservice to those of us who actually need to make a living outside of hothouse environments. This is doubly true for the people who then proceed to leap onto forums and scream and holler until they get what they want.
2. “I saw {x} on Somebody Else’s site, and I want you to implement it on mine.”
It’s hard for me to be upset with these people, at least until they utterly fail to understand the constraints, caveats, and cost concerns that usually attend such requests when done right.
…And as for commitment: people in general are wired to maximize their return on investment of effort. When that return is measured in dollars, I imagine that Web developers are no different in their differences and similarities than other professionals.
Abusing vendor prefixes is a great way to pander to that reality, and a lousy way to keep the Web from breaking. I’d rather face something like this than the “to hell altogether with the other vendors’ implementation of this feature” attitude that was prevalent until ten or so years ago… but it will have the same effect: product will take more time to build and test than if we stick with the status quo. Frameworks can help with that problem, but only so much.
Beyond that, it feels like the responsible authorities are trying for a repeat of HTML 3.0. That wouldn’t end well at all.
I came to make a point, but Adam Pflug already made it so I’ll just have to expand on it.
“border-radius:5px” means “border-radius as defined by the CSS spec”. As long as the spec is final and everyone agrees on what it says, developers can use this and browsers can implement this.
“-webkit-border-radius:5px” means “border-radius as defined by the Webkit implementation”. As long as this implementation is final and everyone agrees on what it is, developers can use this and browsers can implement this.
There is no difference between a CSS property that is defined “officially” and one that is defined by a browser, provided that the two criteria above hold. If they don’t then it would be a bad idea for browsers to copy another browser’s implementation, but I’m sure they will only do this for features that are considered stable enough.
This does bring up a new problem, which is that it almost condones browser vendors coming up with their own fancy features outside of the standards process. After all, if webkit implements -webkit-blink and it catches on, other browsers can simply copy the implementation. However, this is a completely separate problem and I hope browser vendors remember enough about history that they will avoid doing that.
Pingback ::
CSSquirrel : Vindaloo Fart | opinions and news on web design by Kyle Weems
[…] And please read Eric Meyer’s pessimistic, but perhaps realistic, assessment of the issue in Unfixed. […]
@Milo: Problem is: properties defined by a browser are not _really_ defined. For example, I defy you finding the specification for Webkit’s early gradient syntax. You won’t find anything complete.
Therefore, it’s very difficult for a browser to implement properties found in another browser, even if it is open source. See how the .doc format took ages to be supported by Open Office (granted, Word is not open source).
Best example given in those W3C minutes:
that once vendor extensions are implemented in other browsers we are stuck with them forever, just like the User Agent string
That’s a paraphrase, but it was a great example.
Pingback ::
TL;DR on Vendor Prefix Drama | Transition Timing
[…] Meyer is pretty sure we aren’t going to win this […]
Great presentation Eric, it’s a shame to see much of it outdated almost instantly.
I wanted to make a comment, but kept thinking of Remy Sharps post http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south I think the section detailing Who’s guilty is telling.
Here’s hoping for the best
Pingback ::
Die Sache mit den vendor-prefixes « F-LOG-GE
[…] unfixed […]
Pingback ::
Browser vendors suggest supporting -webkit CSS prefixes « Netlight on Web
[…] Eric Meyer: Unfixed […]
Here’s my modest proposal. I like this whole “experiential” prefix idea, so I’m going to run with that.
A browser should support three formats: -x-, -vendor-, and the unprefixed version.
-x- support would be interchangeable with -vendor-, making -vendor- necessary only when the syntax differs for the vendor (gradients being the poster child here). So for almost every property, it would only be necessary to specify -x-property: 5px; property: 5px; If Firefox’s support differed, you would add the appropriate -moz- property (probably first, so that -x- could supersede it when Firefox catches up.
Since -x- doesn’t exist, this might be more of a “going forward” fix rather than cleaning up anybody’s current mess. For this to really work, it would be important to un-prefix as many current properties as possible (and be faster about un-prefixing new ones as they come along). That way, -x- would really be for newer, experimental properties.
Pingback ::
TL;DR on Vendor Prefix Drama « JoinOG
[…] Meyer is pretty sure we aren’t going to win this […]
Pingback ::
Ten interesting things I read this week « « Jeffrey Sambells Jeffrey Sambells
[…] Unfixed […]
Pingback ::
The -webkit- Controversy | zarjay.net
[…] developers to take action. All my favorite web gurus are voicing their opinions (Peter-Paul Koch, Eric Meyer, Remy Sharp). And there’s enough dramatic headlines to go […]
Pingback ::
Testing for website compatibility in Firefox on Android | Aaron Train
[…] and what to do moving forward. There are plenty of interesting and relevant posts out there as of recent with varied proposals and potential solutions. This posting is focused on some of the […]
I’ve been using vendor prefixes for a few years now and I’m definitely glad to see the latest versions of browsers accepting “border-radius,” for example, without a prefix. This needs to be the direction we continue to seek if we want to uphold web standards.
It was always the direction we were seeking, Bahis. The key to prefixes was the eventual dropping of prefixes, once implementations became interoperable. Prefixes were meant to make it much easier to get to that final state without getting painted into a corner along the way.
So, isn’t Internet Explorer 9 earlier than Firefox 4 to support box-shadows, in unprefixed forms? I don’t really know, but now even unprefixed gradients are supported!