If you’re starting to incorporate some HTML5 and CSS3 into your pages, then you’ve probably also looked into the possibility of polyfilling those features for older versions of IE.
Of course, you could instead opt for “progressive enrichment” and leave IE in the lurch while prettying things up for the newer browsers. That’s the method that Andy Clarke recommends, and it’s certainly a valid option.
But if for whatever reason (usually something political or the fact that the client demands it) you have to give IE a similar experience, then you face a very bizarre circumstance.
The Pickle
The newer browsers (Chrome, Safari 4+, Firefox 3.6+, IE9) get the clean, optimized, standards-compliant, best practice code.
Internet Explorer versions 6-8 get the scripting hacks, jQuery plugins, the IE-only filters, the extra stylesheets, the CSS hacks, and other horrors.
And let’s not forget that for many client projects, you’ll end up serving your slowest code to the most users — IE users.
Do you see the problem here, besides the fact that this whole thing becomes a maintenance nightmare?
Shouldn’t the Good Browsers Get the Junk?
The truth is, IE6 and IE7 cannot handle those extra scripts, filters, and CSS hacks well at all. Those browsers are slow, and they are almost always on Windows XP, which makes them even slower.
IE8 is better, but is still slower than its competitors at handling scripting, and many IE8 users are still on Windows XP too, making IE8 much more prone to crashing and overall slow page rendering.
Think about it: In any battle, you always want the toughest competitor facing the toughest challenge; you never throw your weakest competitor into a difficult fight, because you know he’ll lose.
If Chrome, Firefox 4, or IE9 had to absorb those scripts and hacks that we throw at IE6-IE8, it probably wouldn’t be so bad; those browsers are built to handle much more. But that will never happen.
Instead, we have a bizarre pickle to deal with: We give earlier versions of IE tons of junk that they handle quite poorly, and we give nice clean and optimized code to the toughest and most stable browsers.
Knowing the importance of branding, the crucial need for page speed, and having knowledge that Google now considers page load times in their search results algorithm, this is quite a problem for any development team that needs to support older versions of IE.
This is an interesting and timely article as this is a topic I have been considering recently.
I am struggling a little to get your point – are you saying instead of wrapping pollyfills in conditional statements we should just serve them up to all browsers or are you saying we should not be pollyfilling?
Oh, no, I’m not saying that the way we’re doing things is wrong. Also, it’s going to vary from project to project, so I can’t make any definitive statements anyhow.
Basically, I was just pointing out the catch-22 nature (for lack of a better term) of cross-browser development. It’s just nonsensical that at this stage of the game we’ve come full circle from the days of “code forking” during the browser wars and are still serving crappy, unmaintainable code to Internet Explorer.
The browsers that could handle those things better don’t need it. Not to mention the fact that we’re serving the slower experience to our larger audience (IE). Of course, that’s just a fact we have to deal with, and nothing will change it. It’s just a bit bizarre.
Oh, and my articles on here often have no point, so sorry about that. :)
Rule number 1: refer to http://dowebsitesneedtolookexactlythesameineverybrowser.com/
Rule number 2: Serve them, a “dumbed down” IE webpage rather than the full, rich experience.
Rule number 3: If the client suggests it should look and act the same, refer to rule number 1.
Rule number 4: The client rejects your services and uses a different developer instead. :)
Sometimes things aren’t as clear-cut as we’d like them to be. A lot of people will gladly throw IE a bunch of hacks and junk if it means keeping the client. They often can’t afford to do otherwise.
I do see the problem with older Internet Explorer browsers. But I still try to keep the code as clean as possible. The less hacks/tweaks I add to be MSIE 6/7 specific, the better the code/structures works on modern browsers.
I actually dont give a D**N about MSIE6 users. I would rather make a popup/slide-in that tells them that R.I.P MSIE 6 – Microsoft have realised it too. So I think we should consider to provide the users with a free choice of selecting a better browser on their system.
I dont use those clearfix kinda messy things. I sometimes add a little “DirectX filter” in CSS, but nothing that will break the output for other platforms. I always develop for webkit and mozilla and then keep MSIE open for testing purpose too.
So my preferede way is to use Chrome for main browser. Firefox for serious debugging through Firebug (good for jQuery and AJAX stuff). Safari I still open to make sure fonts looks okay on Mac and Opera is open for… well just to keep the geeks happy too. Its a great browser, but I still find it slower than Chrome and sometimes it does render stuff a bit different.
So until MSIE 9, I went back to MSIE 7 and MSIE 8 to make sure that the layouts worked okay in Microsoft world too. Rounded borders might get squared, or I did a CSS sprite and used that as method for every browser instead.
If a customer comes to me and demands a MSIE6 compatible website, I send them on to my competitors. I dont wanna develop crappy stuff anymore.
I think that’s as it should be. Users of old, obsolete, junky browsers like IE 6-8 need to be encouraged to move to other browsers by any means that the client can live with. Sometimes they’re fine with not having some of the “polish” (or they don’t even notice it’s missing); sometimes, they do notice, and then have to live with the slowness. Why should that bother end users? Their experience of the web is, as a rule, slow and ugly compared to those using modern browsers. Why would they be expecting anything different?
Tell me about it!! What frustrates me is how many clients won’t listen to the sound advice that users with older, slower browser are better served by (and arguably in some cases deserve) a less aesthetically pleasing/wowing experience.
IE 6 and even IE 7 is like someone insisting they want to rent a movie on Betamax when DVD and BlueRay are the only practical options. We need to stop obsessing with supporting anything but the most recent technologies, it’s just too expensive to maintain when even Microsoft has clearly moved on. We do not support any IE6 development and my design firm will drop IE7 support sometime next year.
I agree — if the usage share for IE6 and IE7 is insignificant.
You have to remember that high volume traffic may require some level of support for IE6 and IE7. Maybe not for a really complex web app, but for something simpler.
To illustrate: A website that gets 500 visitors a month, may only get about a half-dozen on IE6 and IE7, depending on the niche. But a website that gets 20,000 visitors per month, even though it has the same percentage of users on IE6/7 as the other site, now has more potential conversion rates to be concerned with.
If you wouldn’t have explained the actual meaning of your article in the post I also wouldn’t have known what your point is.
The extra CSS that you have to add for older browsers is the reason why I still not use Modernizr or similar scripts at projects. I actually can’t quite see the point why I should use it. I use Conditional Comments for the IEs and if I have to react to a particular browser (which doesn’t happen very often) I use the CSS browser selector script (http://rafael.adm.br/css_browser_selector).
Beyond that I am a supporter of progressive enhancement – everyone should see waht his/her browser is capable of. Although there are cases when you also want the IEs to have some CSS3, where CSS3 PIE (http://css3pie.com) comes into play. I am a real fan of it.
I see the solution to your complaint quite obvious when applying on it the rules of Progressive Enhancement.
I see the basics as:
1. Never target a specific browser – Use modernizr or other tool to detect features.
2. Create the basic HTML and CSS to set a simple visual baseline.
3. With media queries target page widths starting form the narrow to the wide.
4. Adding visual sugar using the classes provided by modernizr (.cssgradients, etc.)
5. Do the same with your js – Use modernizr to apply visually expensive code only to feature rich browsers.
Interesting point. To summarize:
1. Are you losing clients, or is your client’s business hurt when you throw demanding code at older browsers?
2. We know older browsers have troubles with code that’s suppose to make them modern. Are you losing clients because the site looks different in older browsers even if it loads faster and performs better for them?
So which is the NOT WANTED scenario between the two?
I absolutely abhor troubleshooting IE6/7/8 issues, but usually I find that if I can make it look right in one of those browsers (well, IE7/8 anyway), Safari/Chrome/FF work too. It usually comes down to unique strictness in the way the box model is handled on the part of IE.
It’s kind of funny sometimes how I can start with a page that looks great in S/C/FF and looks like a train wreck in IE, make a bunch of changes, and then find it STILL looks great in S/C/F but also works in IE.
If these more modern browsers are anything they are resilient.
A great informative article on the browser’s performance. Basically talking on IE versions is great.