Blog

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.

So what is this whole PIE thing, anyway?

The documentation states it not quite so candidly, but here it is from my perspective:

PIE is an answer to a constant frustration. The frustration that no matter how much I want to be able to use the elegant decoration properties of CSS3, and no matter how many other browsers already support them, I won’t be able to realistically use them in serious client work for probably several years. At least until the current crop of IE browser versions shrink to negligible market share.

And that sucks. Big time.

As web developers, working with the “lowest common denominator” has always been the price we’ve had to pay for the great freedoms, accessibility, and reach that the Web gives us. I generally feel that the trade-off is worth it, but still it’s a huge pain in the ass, day in and day out. In my opinion it’s become even more difficult to deal with in the past year or two, due to the growth of modern browser share, the new browser performance race, and the explosion of advanced mobile browsers. It’s hard to look at these things, and see what could be possible were it not for that blasted IE piece of crap, and not tear your hair out in frustration.

In early 2010 I had the opportunity to work as co-architect on a version of the realestate.com.au web site for advanced smartphones, as part of my job at Local Matters. As there was a separate version for other mobile devices (“dumphones” as we like to call them), we were able to tailor this view specifically for phones with advanced WebKit browsers, e.g. iPhone, iPod Touch, Android, and WebOS devices. All of a sudden I was unconstrained by the shackles of IE, and was able to use CSS3 for the first time in a real-life scenario. It was liberating! We were able to achieve a beautiful page design with practically no images; development was incredibly fast and easy, and the site’s loading and rendering performance was blisteringly fast. The huge advantages of CSS3 decorations came into sharp focus.

When the project launched and I had to go back to working with IE, it was a huge letdown. I immediately started tossing ideas around in my head about ways I could make things less painful, and on evenings and weekends threw together some rudimentary code experiments. I was greatly inspired by Drew Diller’s DD_roundies which proved you could reliably render VML behind an element to implement complex box decorations. The first experiment was a rudimentary implementation of border-image; the next was a simple box-shadow with blur, but for square boxes only.

Over the next several weeks these silly little experiments slowly evolved into something serious and powerful. Separate scripts became a single HTC behavior. Fragile regular expression matching was replaced by a real CSS value tokenizer. Half-assed approximations of features became in many cases fully compliant implementations. Support for rounded corners, gradients, multiple backgrounds, etc. were added. Optimizations for size and performance were integrated. And so on.

By that point I realized I was on to something potentially huge. And it needed a name. I threw some ideas around with my wife and some friends, and eventually decided on “PIE”, standing unofficially for Progressive Internet Explorer.

And that’s how PIE came about.

Well it’s that time… the css3pie.com site has been up for a while but sitting pretty much empty, and that’s just not cool. I’m so incredibly excited by the potential of this project, and I need to get the word out there! So I’m writing this first blog post to get things rolling.

PIE has been in limited alpha testing with a select group of developers for a few weeks now, and I’m feeling good about the feedback so far and its readiness for real-world usage. But in terms of communicating what it’s all about and how to use it… we’ve got a long way to go. So getting the website together has become my number one priority.

Unfortunately this is the difficult part for me. I’m a true gearhead, so the coding and testing part comes naturally to me and I love doing it, but give me a marketing task and my eyes glaze over. Thankfully I have my awesome wife to help me out; she’s thrown together some incredible designs for a project logo and overall brand that make me absolutely giddy. And we’re working together on content for the site; I’m very thankful to have her input as she’s not a super-technical developer (a large part of my target audience!) and can help guide things based on her perspective. So expect all this to come together in the next couple weeks, followed hopefully by a public beta launch!

My next post will be a sort of high-level introduction to PIE and the history of how it came about.