PIE and Vendor Prefixes

For a long time, it was the common wisdom that any CSS properties or values implemented by a browser vendor which were not part of a ratified CSS specification should be given a vendor prefix, e.g. -moz-border-radius or -webkit-gradient, to make it clear that they were browser-specific. But in recent months that wisdom has been challenged by many of the industry’s top minds, and some have called for the dropping of prefixes entirely due to their verbose nature. Others have defended prefixes as necessary, but proposed changes to the standards process to make them easier to work with.

Among browser vendors we have started to see some of the prefixes being dropped. IE9, for example, is implementing several of the CSS3 Backgrounds and Borders properties with unprefixed names. Opera has done the same for several properties, and WebKit has started in that direction as well. But this trend is by no means consistent. It’s still pretty unpredictable if and when browsers will drop their prefixes.

PIE, just like the browsers, is implementing features which are defined in working draft specification documents. Some, like border-radius, seem mature and unlikely to change. Others, like background gradients, are very young and may change drastically in the future.

So how does PIE handle vendor prefixes? The answer is pretty straightforward:

1. PIE does not require any vendor prefixes for CSS3 properties which are not supported natively by IE. This means that you can use border-radius, box-shadow, etc. without prefixes.
2. PIE also recognizes, and gives preference to, any CSS3 properties with a -pie- prefix. So if you really needed to give a unique value to PIE for, say, box-shadow, you could do so by specifying -pie-box-shadow. The only reason you would probably need to do this would be to work around a bug in PIE’s implementation, which is hopefully extremely rare.
3. PIE requires a -pie- prefix for any CSS properties which are natively supported by IE. This is a technical requirement, not a philosophical one, due to the fact that if IE encounters a property whose name it knows, but whose value has parts it doesn’t recognize, it will throw away the actual value and give you a default. You’ll run into this most commonly using multiple background images or gradients; if you put those CSS3-only values in a plain old background property, IE can’t give PIE the actual value to parse. So you have to use -pie-background instead.

There’s a reason PIE can be so liberal about using non-prefixed property names, which may not be obvious: unlike other CSS3 implementations, which are tied to a user agent which is unknown to the site author (the user’s browser), with PIE the site author always knows the details of the exact version of the implementation being used. That is because, of course, the site author has delivered the implementation himself by linking to PIE.htc. Thus, as far as PIE is concerned, you don’t have to worry about your CSS being future-proof. If it works in the version of PIE you deployed, it will continue to work exactly the same until you decide to change the version of PIE being used. Future-proofing for other browsers, of course, is still necessary.