Media Temple Hosting

Coding for IE6 = Progressive Enhancement

Coding for IE6 = Progressive EnhancementIt was disappointing to see the unwarranted uproar that occurred in the comments of my article on Smashing Magazine on cross-browser CSS. But in retrospect, it was probably a good thing, because a more important (but related) issue was brought to light in the discussion.

At this stage in modern web design, all front-end coders should at least be familiar with (if not very capable of implementing into their projects) the concept of progressive enhancement. In most cases, we tend to associate progressive enhancement with JavaScript and CSS, and rightfully so, because those technologies help us layer our functionality in a way that makes a website accessible to as many people as possible.

But progressive enhancement isn’t just limited to what we accomplish with fancy Ajax, jQuery, and CSS3 — that’s just part of it (albeit a very significant part). I would like to take the Wikipedia definition of progressive enhancement just a little bit further. Here is the definition:

Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing those with better bandwidth or more advanced browser software an enhanced version of the page.

Although that definition works fine for accessibility purposes, our project goals are much larger. They involve branding, conversions, clickthrough rates, and sales revenue.

For virtually every website we build for our clients, the ultimate goal is creating an experience that will optimize conversion rates. Designing with progressive enhancement allows a website to reach the most people, and because of this, will ultimately achieve higher conversion rates (or at the very least have the potential to do so).

What Does This Have to Do With IE6?

While my article on cross-browser CSS instigated this discussion, some more important points were made in the comments by someone named “Bair”. I’m going to give him full credit for enlightening me further on this matter, and quote some of his words here, because I think he puts it quite well:

Progressive enhancement is the prettier cousin of graceful degradation. Progressive enhance your designs from IE6, don’t degrade your designs to work with IE6. An IE exception is rarely necessary when enhancing designs. When degrading designs there is too much reliance on IE exceptions. source

If your code for IE6 is incorrect, you are doing it wrong. You can perfectly start with IE6 and code your HTML and CSS correctly… I very rarely need IE exceptions in my designs… I’d say this reliance shows you aren’t coding your HTML and CSS correctly first and foremost, regardless of which browser you code in. source

The first thought should be: How do I make this work for IE6 while adhering to standard code? That mindset creates designs that need no exceptions, and provide the best experience to those lower on the technology/accessibility scale. IE6 should not be an afterthought. If IE6 is the starting point for a design, you can make it render the best representation of the design. I haven’t heard of any modern browser that has troubles with standards compliant code that initially renders fine on IE6. source

Standards-compliant code built with IE6 in mind is far less bloated than standards-compliant code build for modern browsers, and made to work backwards for IE6+ with exceptions, style sheet overrides or ie7.js. source

Although much of that discussion was really not directly related to the main topic of the article, the points Bair made (which were in response to the negative comments others made about my advice to “use IE first”), are in line with what we understand today about accessibility and progressive enhancement.

Compare JavaScript Off vs. IE6/7 Usage

How many of those who commented negatively on the advice to “use IE first” would ensure that content in their projects is accessible to users who have JavaScript disabled? Jeremy Keith and many others have for years been emphasizing the importance of accessibility through hijax. They do this even though they are aware that very few users (percentage-wise) would actually see the degraded experience.

For example, this report from 2008 gives a percentage of 6% for users without JavaScript enabled. That’s a very small number, yet we still promote best practices that dictate that those 6% access all content.

Now, I realize that making websites work with JavaScript disabled will also help SEO and mobile access. But if the usage stats for IE6 for our client websites show anything higher than 6%, would we not be behaving somewhat hypocritically, claiming that we promote progressive enhancement while ignoring such a large user base?

IE Usage Stats

The latest browser usage stats are almost 30% for IE6 and IE7 alone. That’s a huge number that should not be ignored. Correctly implementing progressive enhancement (not just for JavaScript, Ajax, and CSS3) will help you reach that large audience in a more effective manner, doing so with code that’s not slow, bloated, and unmaintainable (because of extra stylesheets, CSS workarounds, etc).

Of course, IE6 can still be “accessible” in a technical sense — even with a broken layout and missing transparencies, etc. But is it really in our best interests to visually lock out that many users when it could mean lower conversions, fewer sales, and a much less effective branding effort?

Clearing Up Misconceptions

And just to clarify, this does not mean that I’m encouraging that developers code for IE6 and IE7 using less-than-standard code without giving much attention to the other browsers until the end. The purpose of using IE6/7 first (or very early) is to create a layout that minimizes hacks, workarounds, conditionals, and other junk that will be inevitable if you only check IE at the end. The layout should be checked early in all browsers, including IE6/7 and a more modern browser like Chrome or Firefox. The exception would possibly be when you are designing a niche site in an industry where IE6/7 usage is very low (i.e. 0-5%).

So, my advice to all front-end developers is: Learn the ins and outs of CSS, and learn what is good code, and how elements and properties should behave. If you do that, then you’ll have no problem creating a standards-compliant layout that works nicely in all versions of IE, and will thus have the potential to reach anywhere from 15-30% more users than would be the case otherwise. And when I say “reach”, I’m talking about accessibility, visual effectiveness, and overall branding.

Progressive enhancement is here to stay, and in my opinion, coding with IE6/7 in mind very early in your projects is the only way to truly apply progressive enhancement principles in a realistic way that benefits our clients.

22 Responses

  1. krisztian:

    I agree with you at some points: it is possible to write IE6 compatible code and make everything work. What I don’t like is that requires twice the effort. IE6 does not support any of the selectors I’d normally use to speed up productivity, so I always end up searching for workarounds instead of making things done (

    I code for all browser simultaneously, and if I find something that does not work in IE6 but required by the client/my boss, I make it work with IE6-specific CSS or Jquery. IE6 is a thing we have to live with, but I do not think we should let it tie our hands.

    • D3X:

      Although I agree that there is still a significant number of users on IE6, the question really is should we still need to focus that much attention towards supporting this browser? I think by up-keeping the use IE6 is actually giving it reason for it to stay around longer, the longer we keep supporting and spending time for compatibility, the less likely an IE6 user would see the need to upgrade.

      The same logic applies to designing a site with IE6. It’s clear that this browser has already out lived it’s stay, and it’s on it’s way out. So designing entire sites specifically for IE6 first will only hinder the whole process whether it’s time, technology or design. You can develop perfectly fine IE6 sites, but at what sacrifices and cost?

      I personally design and code for all browsers, and keeping HTML and CSS clean and minimal, I hardly run into layout or CSS incompatibility issues even for IE6 or IE7. And like Kristian says, apply the IE-Specific CSS to fix any issues or consolidate / compromise certain pixel perfect issues so that the design looks the same in all browsers.

      • Craig:

        I SO I agree, D3X. If IE6 users can’t get to any websites, then they have to upgrade. I say, route all IE6 users to a web page where they can find the upgrade they need, and be done with it. They’ll get the hint. Frankly, I think it’s the only way HTML5 is ever going to be usable.

        I’m tired of sales people making the calls where technology is concerned. “Sure, we’ll do it in IE6.” Writing checks our bodies have to cash, then complaining because the client is about to walk because we are slow to deliver. I mean, come on, guys! These aren’t Word documents we’re making here!

        And, why IE6? Because of the customer count? By my count, people buy new computers when the old ones won’t work like they want anymore. They call it planned obsolescence. Why not obsolete IE6? Plus, I bet most of the IE6 users would upgrade if they knew how, and if they knew the security risks of keeping IE6. I don’t use Chrome, but I installed it for my mom (almost 80) because it was lightweight and fast. One down, how many to go?

  2. Zlatan Halilovic:

    *Offtopic* Imagine if all web designers stopped developing for IE6 and IE7, and started educating people not to use those old browsers. After all, a lot of people who use them either don’t care or don’t know that there are other, better browsers. Why should we spend our precious time for those ignorant people, who can’t spend a couple of minutes of their time just to download and install a new browser!? And yes, I know that there are people who must use IE6 in corporate environments, yadda yadda…but there are very few of those, and even they (corporations etc.) are seriously considering an upgrade. Of the 30% that use these old browsers, at least 25% are those that don’t care or don’t know that there are better browsers, and that they are just a click away. Now imagine if we stopped developing for them, but instead educating them about their choices and forcing them to upgrade. I know it’s a fairy tail, but to me everything that can be conceptualized, can be realized.

    Sorry for the “spam-like” comment Louis. I just felt the need to say what I have to say. However, I did read the article and I find it very good :)

    • “Why should we spend our precious time for those ignorant people, who can’t spend a couple of minutes of their time just to download and install a new browser!?”

      Because that’s our job. We’re paid to make it work for “those ignorant people”.

      “Of the 30% that use these old browsers, at least 25% are those that don’t care or don’t know that there are better browsers, and that they are just a click away.”

      25% of all percentages are made up on the spot. Can you cite your source?

      • Zlatan Halilovic:

        ok, I admit it; I came up with those stats, and that was incredibly unprofessional and stupid of me to do, but my point was that if we stopped caring and supporting it, then they would HAVE TO UPGRADE. Take google for example. If such a large corporation that’s trying to control the Internet itself had done it, then so can we.

        • Jim Bob:

          If you’re doing work for yourself then it’s pretty simple, but when 25% of your clients traffic comes from IE6, you can’t just tell them no.

          Unfortunately a lot of e-commerce sites need to have IE6 support as a lot of shoppers browse/buy while at work and their internet security policies keep them stuck on IE6.

  3. Greg Guida:

    I really like Bair’s idea on creating a design for IE6 and then building up from there. However I can tell from the way he talks about it that he is a very experienced developer who was trained using IE6 or earlier and thinks of the web as IE6 being the standard and everything else being added on top. I however am a relatively young developer who was taught in a standards compliant way and for me to try to think of IE6 standards as what i can work with is almost impossible. I really enjoyed the original articles viewpoint though and I truly respect “bair” for being able to think of designing starting with IE6.

  4. Al Scott:

    Anyone who has worked with any corporate client (so pretty much anyone who has worked in marketing) knows that big corporations are almost always locked into old OS and browsers.

    Regardless of how hard you try to educate the guy on the other end is inevitably checking everything you do on IE6 or IE7 for approvals, sign-offs etc. He probably would like to upgrade, but can’t because the system is locked down. He can’t go ahead and approve something when it looks messed up for him, no matter how much you assure him that it will look good on “real” browsers, and that his target audience isn’t going to be using IE6.

  5. I too think that we should discourage and where we can actively *not* support IE6 in order for us to move forward as an industry, it is in the best interest of developers and clients.

    In those cases where this is not possible, what to do? I do agree with *checking* in IE6 and 7 early. That is an entirely different point than starting with it and using it as base for development though. Allmost everybody agrees that that is a bad idea, hence the many disagreeing comments on the SM article. I think that in that same article, you suggested including hacks and workarounds in your main files, another point where pretty much the entire industry disagrees with. We have standardized ways to clearly seperate hacks from good code now.

    In many ways I find that the advise you have given in that article is wrong, against common best practices and dangerous to newcomers. It is the world upside down, it is where we are coming from, not where we are heading towards.

    I don’t fully agree with this “Bair” guy either:

    “The first thought should be: How do I make this work for IE6 while adhering to standard code? ”

    You CANT. IE6 does not understand standard code. Many standards-based layouts and CSS properties DO not work as they should in IE6. While it is true that these bugs are well documented, it requires hacks to solve them. Coding hacks as a base into your standards code is a poor practice no matter what way you look at it. Unless your are doing nothing but highly simplistic layouts with tables, free of any sophisticated javascript and styling, you are screwed.

    • Ferdy,

      Thanks for your comment. And thanks for sounding reasonable (unlike much of the conversations that occur on SM).

      First of all, no I did not encourage the use of hacks and workarounds in main files. I did not say that in the original article. I did, however, say in a comment that if you only have to use one or two hacks, it makes more sense performance-wise to include those hacks in the main styles. Yes, it’s best practice to separate IE hacks/workarounds, however, it’s also best practice to optimize your website for speed. Adding a whole new stylesheet for 2 lines of CSS is just plain wrong, because you’re adding an extra HTTP request. Minimizing HTTP requests is recognized as one of the best ways to optimize for speed.

      So, either you break the “rule” of optimizing for speed, or you break the “rule” of separating styles for IE. I choose to optimize for speed in that case, so I won’t separate a few lines into another stylesheet. I don’t think either advice is “wrong”, and I don’t think it’s correct for you to say that my advice in that regard was wrong.

      Secondly: You said that “IE6 does not understand standard code”. That’s completely false. Many people in the comments of that article have continuously made that false statement, without actually giving examples.

      What you (and they) mean to say is “IE6 doesn’t support all the same properties and selectors as the other browsers, and it has some bugs”. I documented every CSS difference between IE6/7/8 in this article on SM last year, and it also includes all the bugs that occur in those browsers. Almost all the “differences” and “bugs” listed are essentially irrelevant to getting a layout to look the same in IE6.

      Yes, because of its weaknesses, IE6 limits us; but so do mobile devices; so does SEO; so does lack of support of CSS3 across browsers; so does the lack of CSS animation in anything but WebKit; so do users without JavaScript enabled; so does the fact that web users don’t read (they scan); and the list goes on and on and on….

      If we code and implement progressive enhancement for all those things I just mentioned (many of which are very small percentages of users), but we ignore 15-30% of our users, then we’re not really applying progressive enhancement, we’re just doing what the web design community convinces us to do. It’s a trend to ignore IE6 — but that trend is bad for business. (Keep in mind that when I refer to “progressive enhancement” here, I’m using the term very loosely, the way I have in this article; the actual Wikipedia definition is accurate, I’m just expanding upon the principle of it, for these purposes.)

  6. Although I thankfully haven’t had nonsupport IE6 for about 6 months now, I think Bair summed up progrssive enhancement nicely, and he’s right. Your sites should always look almost perfect in ie6+ without even trying if you’re coding semantically and correctly. I use CSS3 quite often and have never had a problem with IE, as most users don’t notice the rounded corners or drop shadows missing.

  7. So very true. IE6/IE7 should be at the start of the development and especially when one have laid the foundation and markup for a site. Not doing that would be absolutely crazy since one then at a later stage may have to go through 10x the more code just to find some quirk.

    I always debug actively for IE6/IE7 and add progressive enhancement (think tr:hover as a progressive enhancement that doesn’t work in IE6). However i think one shouldn’t go crazy with the progressive enhancement either and adding stuff like :hover to every possible element since;
    a) Misuse of the :hover isn’t that user friendly since most stuff that uses :hover are links thus having a zillion stuff that :hover is confusing
    b) :hover on unsupported elements in IE actually slows that browser down

    All in all it’s a non-problem since every real developer tackles these sort of problems anyway without the need for any fancy words. :)

  8. I don’t mean to be mean here, but it sounds like this Bair person is living in 5 years ago. Because it’s been that long since I coded a website to work in IE6 from the start, and worked on the other browsers next.

    Let me first be clear on this:
    I know that there are corporate environments that use IE6, and are locked down in it, and cannot upgrade. I know that there are intranet sites, and certain (mostly legacy, and specialty) software that will only work in IE 6.

    All the being said, there is still no reason to support a 9 year old browser.
    There are 2.5 updates to the Internet Explorer family, 5 updates to Webkit, (nearly) 4 to Mozilla, it’s time to move on, browsers are not like fine wines, they don’t age well.

    I disagree with your reply above Louis,
    Sure you should optimize your website for speed, I fully agree there, but I also believe that you should make your website easily maintainable.

    You say that it’s a trend to not support IE6, I say it’s a trend to make every damn image your CSS uses into one massive sprite. This is the opposite of easily maintainable, and while it does limit the number of HTTP requests, it bogs down the whole process with one massive file that needs to be downloaded and interpreted. Make a couple of different sprites for each group of images. This way if you change the size of one image, you only have to change the CSS of 3 or 4 elements instead of every single one.

    So while you say don’t make an IE specific stylesheet because it bogs down you’re site with an extra HTTP request, you are forced to use extra classes and IDs in your CSS and HTML, because IE doesn’t understand one CSS selector.
    All those bytes add up.
    But you’d never know that because you started from the begging with bloated HTML and CSS.

    @Amber Weinberg
    Many clients I’ve dealt with do notice those subtle differences of CSS3 between FF, and IE, but they don’t mind it. Maybe I’m just lucky, and I’ve dealt with competent people who realize that every browser is different, and accept it.

    I also agree with the statements made above, developers need to stop supporting IE6. I haven’t supported it for about 2 years now, and not one person has complained. Google has dropped support for it on their products, it’s time the rest of the world joined in.

    • Steve,

      Thanks for your comment. What’s interesting is that I totally agree with you on the “sprites” issue. In fact, I wrote an entire article for Smashing Magazine about sprites potentially being a nuisance, because of maintenance and other issues. So I agree, use sprites for small groups of images, but not for all backgrounds.

      But as far as what I said about HTTP requests with IE6/7, I think both ways have their pros and cons. And to me, putting IE styles in a separate stylesheet is more unmaintainable. I like to see the IE hacks right next to the selector for the standard browsers.

      I think the most important thing to do is check IE very early, and make it work *with standard code*, and try to avoid all the extra scripts and hacks as best you can. Neither Bair or I are condoning the use of “bloated” HTML or CSS. I would take a conditional stylesheet over sub-standard code any day.

      Overall I just think it’s somewhat hypocritical for so many developers to claim they make “accessible” websites while ignoring (or serving extra stylesheets and scripts to) what could be as high as a 30% user base

  9. I remember reading that article and thinking finally someone else who thinks sprites are overused and over hyped. I didn’t realize (or probably just didn’t remember) it was you.

    As far as CSS formating goes, that is totally down to personal preference, I’d rather target IE specifically for the little things, it looks cleaner to me, maybe not for you but we can agree to disagree there.

    Depending on whose stats you believe in, IE has anywhere from 65 – 45%

    Broken down version wise, IE7 and IE8 are pretty evenly split, with IE8 always leading by atleast 5%, and sometimes as much as 25%
    IE6 on the other hand is usually far below the other two in the 8%-15% range.

    Personally, I think there comes a time when you just need to stop supporting legacy software. If you support it forever, nothing changes, or you significantly add to the upkeep, and maintenance of the site and the internet in general. I know we as developers can’t force people to upgrade. But we can choose to stop caring.
    And I genuinely do not care about the (up to) 15% of users that will see a site I make that’s broken, or just unusable in IE6. Where I went to school, an 85% was more then good enough for passing.

  10. Henry:

    Well, i’m not totally agree with the purpose of this article. Like many of you, i work with css for a while now, and tried many way to improve my workflow considering browsers compatibility.

    I’m totally agree about to don’t wait until you finish you project on modern browsers for starting to adapt it in IE6/7, you’ll waste your time by finding selectors issues, and write to much hacks as necessary, especially if design is quite complex.

    I personally check layouts and design on every step: i code with Firefox or Safari, then check legacy IE’s when layouts or rules are added. By this way, i realized that many IE “bugs” can be fixed without over-hacking stylesheet:, just site down and think how you can solve your problem for every browser. In most of case, this works, but we still need some specific rules (mainly for IE6).

    Actually, we can’t completely drop IE6 support. As it been mentioned, large companies are still using XP/IE6, and we can’t force theirs internal network service to update thousand of computer only because we (web-designers) think IE6 lived.
    In other hand, for some smaller companies, it’s easiest to speak with them, and honestly
    expose pros and cons of legacy support. In 90% of case, they prefer improved user experience and modern technologies instead of dumbing down everything. The compromise i found is to offer ‘minimal’ support for IE6 (i mean, website is usable, not messed up), but some advanced interactions or nice css/js effects are not available.
    There is no way today to still using gif, or use Flash when JS do the same. (but i do recommand to heavy test your js on IE6, cause modern browsers like safari correct code error, like end array coma, ie6 don’t)

  11. Very good article, it is very important to be precise in your coding and provide the best interface to every browser.

  12. Eli:

    Alright, well… I do in theory agree with progressive enhancement, but in practice I agree with graceful degradation. It creates the best experience for everyone possible if you start with the most basic version of your website, which is usually ie6 with no javascript. You make this a great experience then enhance it from there. However I have only done this once in my 5 years of designing/developing websites. It sounds great, but the fact is many clients don’t want to pay for extra time to do this. I would say that while you are still learning it is very beneficial, to go through this process, but after you have been coding websites for a year or so, and been doing either progressive enhancement, or graceful degradation you learn what will and will not work in most browsers. Then you are doing them both at the same time really. For example, I know every time I code a floated element in a container, and the floated element has a side margin, ie6 will likely double this margin, or I can use display inline-block in some cases to fix this. So I code in modern browsers with ie6 always in the back of my mind, then go back, at the end of html/css stage and fix any display issues with ie6 & 7. If there are only one or two CSS fixes, I typically just add them in ie conditionals in the header of my page to avoid un-necessary http requests, and still keeping them separate from my “modern” css. Sorry for the rant… just had to throw in my two cents.

  13. Very good article, it is very important to be precise in your coding and provide the best interface to every browser

  14. Thanks for the advice! I’m going to try starting my next project in IE instead of Firefox and see how it goes.

  15. nice post. continue good work.

Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field. If you use keywords, your comment will be deleted, or your name will be replaced with the alias from your email address. No foul language, please. Thank you for cooperating.

Instructions for code snippets: Wrap inline code in <code> tags; wrap blocks of code in <pre> and <code> tags. When you want your HTML to display on the page in a code snippet inside of <code> tags, make sure you use &lt; and &gt; instead of < and >, otherwise your code will be eaten by pink unicorns.