I thought of this clever post title back in August and - much like the promises of politicians - it's taken me ages to deliver :)

So, although it may no longer be topical, I still feel it nicely sums up the "here and now" of web development, and "where we are at" in terms of CSS3, associated technologies, and browser support for them.

It was all the way back in 2008 when web developer heavy-weight Eric Meyer wrote "JavaScript Will Save Us All". An article where he basically says that we should use JavaScript as a "translator" of new CSS that older browsers don't support, so that we can use this new CSS in our projects, have it render correctly in modern browsers, and have the desired effects and behaviors render as we wish in "IE the Elephant" - there or there abouts in some cases.

For example: IE6 doesn't support :hover on tags other than a. So instead of adding classes to our mark-up and extra CSS, we can add a rule to an IE6 only JavaScript file to get that behavior working as we would like in IE6. Javascript is acting as a crutch, so to speak.

That was then, what about now?

Well, 2 years on and the "JavaScript go between" method is widely adopted by developers on both personal and commercial projects. When you consider that Modernizr won the Open Source Application Of The Year Award at the 2010 .net awards, that tells you all you need to know about the importance and usefulness of JavaScript as a method for enabling the use of HTML5, and filtering new CSS and associated technologies into widely used, older browsers.

Using a library such as jQuery, with solutions such as Modernizr, Selectivizr, dd_belatedpng, dd_roundies and others, we are armed with an arsenal of methods to enable "support" where there otherwise is none. There is an ever increasing number of jQuery plug-ins that are being developed to help us tick the older browser box.

What about other "hacks", such as filters?

There are those who say that you should never use IE filters. I'm of the opinion that, once more, it's "shades of grey".

If you have a website where you are already calling a Javascript library for other purposes, I would say it is better to use JavaScript for adding, say, an opacity effect in IE.

But if you have a site using no JavaScript, I would question whether calling a library, and then adding an individual IE Javascript file containing the function, is entirely appropriate, when you can add "filter:alpha(opacity:x)" to your IE style-sheet and get the same result.

Workarounds / filters are not direct replacements for CSS3

They may often behave and display slightly differently.

Many web design articles and tutorials often throw them in under the heading of "Such and such CSS3 tutorial", without clearly explaining this fact.

I think it is fine and useful to include methods for IE and older browsers, but it should be clearly stated that they are possible workarounds, and not directly part of the CSS specification. It should also be made clear that the way they behave and display may differ to varying degrees, and that extending them in many cases is not possible / can become difficult.

And so. The crux of this post: "Workarounds are essential"

The reality is that IE8 and older still play a massive part in our web environment. Whilst on personal projects, and certain commercial projects, we can degrade quite heavily, it is still often the case that clients want and need a certain result in the IE browsers that is a little more than just "as long as it looks OK and works".

For example: I have a client where rounded corners and drop shadows are more than just "enhancements". They make up an important part of their company brand aesthetic, and continuity across both print and digital material is a must. Having such design attributes missing from a core user group was deemed unacceptable to my client - and  I had to agree. This stuff's important. Especially when you consider the amount of time and money a company often invests in getting their brand just right.

But at the same time, the product I was developing for them required flexibility that only CSS3 could provide. So workarounds for IE were a must if I was to keep brand continuity, but also use the CSS3 methods to ensure the product was extensible and future-proof.

The end result was: if I didn't use workarounds to match the CSS3 generated aesthetic as close as possible in IE, I was not getting sign-off on my work. If I don't get sign-off on my work, then this new product, with all it's CSS3 goodness and enhancements in modern browsers, was not launching at all. I needed the nasty stuff - the workarounds, filters, hacks etc. - so the good stuff could be made a reality.

This is where the "coalition" comparison is made. Much like the polls in the 2010 election, the stats for IE use are what they are. Our efforts as developers, and the efforts of browser and OS developers and such, are making usage stats drop, but this is where we are at.

For the Conservatives to get in power they needed The Liberal Democrats, and for my project to get sign-off, I needed IE workarounds.

Finally, I must point at that the above project is a specific example that had specific needs, so I'm not saying that the approach I took is appropriate for all circumstances. Once more: "shades of grey".