06-07-2010 A List Apart: Articles: Prefix or Posthack
JULY 6 , 2 01 0 N o . 3 09
Prefix or Posthack
by E RI C ME Y E R
Pu blish ed in : Browse rs , CSS
As C SS browser support increases, including impressive strides by the
IE9 team, more and more authors are plunging into C SS3. As they do
so, they’re facing vendor prefixes—the -*- properties like -moz-
border-radius, -webkit-animation, and so on.
Perhaps inevitably, there’s been some grumbling about these
prefixes. There have been calls to drop them, or to collapse all the
vendor-specific prefixes into a single prefix like -beta-. The primary
pushback is that nobody really wants to write the same thing four or
five times in a row just to get, say, rounded corners on an element.
While such grousing is understandable, it is exactly the inverse of
what should be happening. We ought to praise vendors for using
prefixes, and indeed encourage them to continue. Beyond that, I hold
that prefixes should become a central part of the C SS standardization
process. I do this not for the love of repetition, but out of a desire to
see C SS evolve consistently. I believe that prefixes can actually
accelerate the advancement and refinement of C SS.
Look back in horror
To understand why we have vendor prefixes at all, it’s instructive to
look back at the box model (http://www.w3.org/TR/C SS2/box .htm l) ,
which almost killed C SS before the turn of the millennium.
Inconsistent box model implementations created a crisis. To escape
the danger, we had to build an entirely new behavior on top of a
markup feature and invent a whole class of hacks.
For the young whippersnappers in the audience who missed all the
fun, what happened was this: In the first round of browsers that
supported C SS, Netscape implemented the box model found in the
C SS specification. That meant that width and height referred to the
width and height of the content area. But Internet Explorer
implemented the intuitive box model, which meant that width and
height declared the dimensions of the box’s outer border edge.
Whichever of the two you think better, the fact remained that there
were two major browsers with large user bases that were completely
incompatible with each other. It was the late 1990s, we were fighting
like hell to leave behind the morass of “this site best viewed in…”
alistapart.com/…/prefix-or-posthack/ 1/6
06-07-2010 A List Apart: Articles: Prefix or Posthack
badges, and here we had a situation where a layout that worked fine
in one browser could completely fall apart in another.
C ompounding the problem was that neither browser could change its behavior to mirror the other. Assume for a moment
that the IE team decided to change their C SS support to reflect the specification. To do so would mean that tens, even
hundreds of thousands of sites that worked in IE would break—would quite literally fall apart, visually speaking—in the
“fixed” version. While the standards community would have applauded the move, the rest of the world would have
written off the browser as unusable. And even if the Working Group decided to change the specification to match IE’s
behavior, Netscape would then have faced exactly the same problem.
Thus DOC TYPE switching was created. The entire regime of “standards mode” and “quirks mode” was born of this
problem. The solutions to other problems were rolled into DOC TYPE switching, but the box model triggered it. Think
about it: because two vendors did things differently, browsers now have to maintain two different primary rendering
models and choose which to use based on an SGML declaration that says nothing about rendering.
Furthermore, the first wave of C SS hacks were devised to address exactly the same problem. The classic example of
the genre gives it away in the title: The Box Model Hack (http://tante k .com /C SS/Ex am ple s/box m ode lhack .htm l) . In fact,
the hack itself was based on flaws in syntactical parsing of voice-family values, but nobody ever called it “the voice-
family hack.”
The funny part is that this wasn’t the only instance where a box model inconsistency lead to trouble. Not long after
DOC TYPE switching saved C SS, the Explorer team implemented some features of C SS positioning. One of the properties
they implemented was clip. Having learned their lesson with the box model brouhaha, the engineers at Microsoft paid
very close attention to the specification and did what it said.
Shortly after they shipped it publicly, the C SS Working Group massively changed the way clip worked. The syntax
looked exactly the same, but yielded very different results.
Once more, the specification clashed with the behavior of a publicly available browser (or, if you prefer, vice versa). The
eventual resolution was to revert to the earlier behavior and drop the new behavior entirely. That renders clip
effectively useless on any element with unpredictable height and width—which is to say, any normal-flow, non-replaced
element such as a div or a paragraph. Although other solutions were proposed, they never came to pass, and clip
withered away.
Imagine a different outcome
Suppose that instead of implementing clip, the IE team had implemented -ms-clip. In that case, a behavior change in
a later specification wouldn’t have been so difficult to overcome. Because a vendor prefix marks a property as “in
progress,” it’s much easier for a vendor to go back and change it. Thus the IE team could have changed the way -ms-
clip worked in their next release, explaining to developers that they were updating their experimental implementation
to match changes to the specification.
Even if they had decided that that was impossible to do, the damage of the “bad” implementation would have been
quarantined in the prefixed version of the property. Other vendors could have implemented the new version of clip
(using their own prefixes), unaffected by what the IE team had done. A single vendor could not pin the specification and
other vendors in place by their actions.
This is the promise that prefixes provide: A way to mark properties as “in progress,” and so not necessarily guaranteed
alistapart.com/…/prefix-or-posthack/ 2/6
06-07-2010 A List Apart: Articles: Prefix or Posthack
to always act the same in future releases; an out for vendors who need to make those changes; and a defense against
bad or premature implementations that happen to ship first. They add sorely needed flexibility to the advancement of
C SS.
Of course, we could just say: “When a browser is wrong according to the specification, then they have to change even if
it breaks the layout of web sites.” With prefixes, that’s a lot easier to accomplish, thanks to the warning that prefixes
embody. Without prefixes, it’s very difficult or even impossible. Microsoft never did change the way it handled width and
height in legacy pages—instead, it used DOC TYPE switching to behave differently on new (theoretically more “standards
compliant”) pages. It was a useful and necessary trick, but that kind of trick only works once.
Even now we suffer
Lest you think that all this silliness is an artifact of history, here are two cases of inconsistency happening right now:
Mozilla and WebKit browsers render box-shadow blurring very differently, and neither fully conforms to the
specification. As I write this paragraph, a lengthy and heated debate is raging on the www-style mailing list. At
least one, and possibly both, implementations will have to change the way they handle shadow blurring to achieve
interoperability. The same holds true for any Microsoft or Opera implementations.
Mozilla and WebKit browsers both support gradients, but they use radically different syntaxes to achieve the
same basic result. Now imagine a world where the vendors had implemented gradients without the prefixes. You
would have three choices:
1. Pick which browser gets a gradient and which one doesn’t.
2. Use C SS hacks or browser sniffing to serve up different styles to different browsers.
3. Walk away from using gradients entirely.
And there are three choices here only because the gradients use wildly different value syntaxes, thus opening the
door to option number one. In a case where two implementations use the same value syntax but have very
different effects—as was true with clip—then there are really only the last two options: hack and sniff to send
totally different styles, or just walk away.
We’ve seen this movie played out many times over the history of C SS. There’s no reason to want to see it again. It was
bad enough the first dozen times.
Prefix or posthack
But are prefixes really any better? After all, it’s been said that vendor prefixes are the new C SS hacks. As Aaron
Gustafson pointed out in a recent article (http://www.a listapart.com /a rticle s/stop-fork ing-with-css3/) , this:
-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
border-radius: 10px 5px;
…is reminiscent of this:
alistapart.com/…/prefix-or-posthack/ 3/6
06-07-2010 A List Apart: Articles: Prefix or Posthack
padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;
In terms of repetition and annoyance, yes, the two are very much alike. But they’re fundamentally different in this way:
Prefixes give us control of our hacking destiny. In the past, we had to invent a bunch of parser exploits just to get
inconsistent implementations to act the same once we found out they were inconsistent. It was a wholly reactive
approach. Prefixes are a proactive approach.
Furthermore, prefixes are a temporary hack. 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
C SS. Without them, we’re just waiting for the next botched implementation that forces us to support it through hacks for
years upon years.
That’s why creating a unified prefix, such as -beta- or -w3c-, is at least half a step backwards. It would preserve
vendors’ ability to mark properties as “in progress” and make changes as needed. Unfortunately, it would completely rob
authors of the ability to excise, or even feed a different value to, one particular browser if it has a botched
implementation. From an author’s point of view, a unified prefix is no better than a world without prefixes.
I sometimes feel the same way about pre-processor methods to handle prefixes, whether on the server side (using tools
like Less) or client side (any number of JS frameworks). When using these tools, it’s possible to just write border-
radius declarations and have the tool expand that into the requisite list of prefixed declarations. On the one hand,
they’re a very useful way to reduce typing and keep the authoring neat and clean. On the other, they’re just like a
unified-prefixed or unprefixed world: one bad browser implementation away from breaking pages.
The advantage is that if something goes haywire, any author can go back, disable the pre-processor, and write out the
prefixes by hand. Alternatively, the pre-processor can be updated to handle the problem. Either way it’s a little more
cognitive overhead for the author, but not too much.
The downside is more philosophical, but it’s no less important for that: By hiding the prefixed properties behind a
processor, authors may forget that what they’re using is experimental and subject to change. C ognitively, they may
start to treat what they’re using as settled and stable when it may be nothing of the kind.
Make prefixes really matter
I believe so firmly that vendor prefixes are a good thing that I’m prepared to take the next logical step: Vendor prefixes
should be made more central to the standards process. They should be required of newly implemented properties and
should be the mechanism by which interoperability is declared.
Here’s what I mean: Suppose someone invents a new property called text-curl. Immediately, three vendors
implement it. Each of them should be required to add a vendor prefix to their implementation. Thus, we’d see things like
this:
h1 {
-webkit-text-curl: minor;
alistapart.com/…/prefix-or-posthack/ 4/6
06-07-2010 A List Apart: Articles: Prefix or Posthack
-moz-text-curl: minor;
-o-text-curl: minor;
text-curl: minor;
}
Over time, the vendors refine their implementations in response to bug reports and clarifications by the Working Group.
Eventually, the Working Group decides that two of the three are fully interoperable. Those implementations then get to
support the bare text-curl. The third does not.
At that point, authors might decide to simplify their styles like so:
h1 {
-webkit-text-curl: minor;
text-curl: minor;
}
Instead of hacks proliferating over time, they’re peeling away. Eventually, we’ll only need a single text-curl line.
So what happens when a new implementation debuts? It uses the prefix in its first release, no matter how many
interoperable implementations already exist. That might mean that we’d have to go back and change the C SS to say:
h1 {
-ms-text-curl: minor;
text-curl: minor;
}
Then, as soon as the Working Group deems the implementation of -ms-text-curl interoperable, the prefix can be
dropped in the next release of IE. At that point the C SS can be reduced to a single, unprefixed line. Again, the number
of hacks dwindles over time.
Of course, each of those vendors will continue to support the prefixed properties, so even if we don’t prune the prefixed
lines, each supporting browser will recognize the unprefixed property and use it (since it comes after the prefixed
declaration). For any browser that implements a prefixed version that doesn’t manage to get to an unprefixed state, its
own prefixed property will still work. Even if the C SS is never touched again, it will continue to function.
Having said that, return for a moment to the time when the Working Group said that two implementations were
interoperable and could thus drop the prefixes. That serves two purposes. First, as I said before, it marks a property as
having enough interoperability to allow progress in the standards process.
But the other thing it does—and this is arguably more important—is force the vendors and the Working Group to work
together to devise the tests necessary to determine interoperability. Those tests can then guide those who follow,
helping them to achieve interoperable status much faster. They could literally ship the prefixed implementation in one
public beta and drop the prefix in the next.
This reverses the way things are done now. As it stands, the process is set up so that when any C SS module reaches the
C andidate Recommendation stage, vendors can drop the prefixes from properties in that module. But that just opens us
alistapart.com/…/prefix-or-posthack/ 5/6
06-07-2010 A List Apart: Articles: Prefix or Posthack
up to the possibility of another botched implementation and a future of hacks to work around the error.
As proposed here, a module would be permitted to reach C andidate Recommendation once all of its properties had at
least two unprefixed implementations in the wild. Any implementations that came after would start prefixed and drop the
prefix once they had proven, in the wild, that their prefixed implementation matched the existing unprefixed
implementations. Instead of being a minor gamble, unprefixed properties would come as close to a guarantee as
anything we’ve seen to date.
Conclusion
If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using
vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with
the process and possibly accelerate C SS development.
So the next time you find yourself grumbling about declaring the same thing four times, once for each browser,
remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in
comparison to the disease it prevents. And in this case, you’re being vaccinated against a bad case of multi-year parser
hacking and browser sniffing. We suffered through that long plague once already. Prefixes will, if used properly, ward off
another outbreak for a long time to come.
Illus tratio n by Kev in Co rnell (http://alistapart.com/authors/c/ke vincorne ll)
Learn More
Related Topics: Browsers, C SS
About the Author
Eric has been working on the web since late 1993 and is the founder of C omplex Spiral C onsulting
(http://com ple x spiral.com /) , co-founder of the microformats (http://m icroform a ts.org/) movement, and co-
founder (with Jeffrey Zeldman (http://ze ldm a n.com /) ) of An Event Apart (http://a ne ve ntapa rt.com /) . A
widely read author (http://m e ye rwe b.com /e ric/writing.htm l) , Eric enjoys a good meal whenever possible and
considers almost no type of music to be worthless. He lives in C leveland Heights with his wife and daughters.
I SSN: 1 5 3 4 -0 2 9 5 C opyright © (http://a listapart.com /copyright/) 1998-2010 A List Apart Magazine
and the authors.
alistapart.com/…/prefix-or-posthack/ 6/6
