In a previous article I pointed out an interesting little trick that was made popular by Paul Irish, and has been added as part of his recently-launched HTML5 Boilerplate.
I love that boilerplate, and I wish I could say I understand everything in it. Paul’s a front-end genius and all developers should pay close attention to what he’s been doing lately.
But I have to say that I strongly disagree with Paul’s inclusion of that conditional comments tip in the Boilerplate, because it does not encourage cross-browser, maintainable CSS, but instead encourages CSS developers to consider Internet Explorer development as an afterthought.
Before I explain my specific reasons for wanting that technique removed from the Boilerplate, I’ll first discuss what exactly I’m talking about.
What’s the Technique?
The technique looks like this:
<!--[if lt IE 7 ]> <html class="ie6"> <![endif]--> <!--[if IE 7 ]> <html class="ie7"> <![endif]--> <!--[if IE 8 ]> <html class="ie8"> <![endif]--> <!--[if IE 9 ]> <html class="ie9"> <![endif]--> <!--[if (gt IE 9)|!(IE)]><!--> <html> <!--<![endif]-->
So, instead of using hacks (which would make your stylesheets invalid), and instead of using external files for different versions of IE (which would add unnecessary HTTP requests), you’re creating a new class on the <html> element for each version of IE. Then, in your stylesheet, you would use something like:
.ie6 .sidebar {
margin-left: 20px; /* dang float bug! */
}
The only browser that would have that style applied would be IE6. So just like that, you’ve saved an HTTP request and you’ve kept your CSS valid. Great tip, and great outside-the-box thinking to come up with something like this. It’s one of those tricks that you wonder why nobody mentioned it before. (Actually, at least one person did, but I guess they weren’t as charming and convincing as Paul!) And the benefits to performance go beyond what I’ve mentioned here, so check out Paul’s original article for details on that.
Wait… Is It Necessary for Every IE Version?
Absolutely not. In my opinion, outside of a few minor instances where IE7 won’t behave, the only CSS hacks or workarounds you should need are those associated with IE6. I wish I could say that you can code valid, cross-browser CSS that works in IE6, but I’d be lying if I did. IE6 has some major issues that need different styles and scripts to get a similar experience. But since IE versions 7+ do not have most of the positioning and layout bugs that IE6 has, then why would you need all these different classes in a default template?
This solution tends to encourage developers to largely ignore IE during development, and just hack it into submission at the end. That’s actually the worst thing you can do when writing your CSS, because it will force you to use hacks or workarounds that aren’t necessary and can be avoided by just coding things to work in IE from the start. And why on earth would anyone need different CSS for IE8 and IE9? If you can’t get a design to look the same in Firefox 3+, Chrome, Safari, and IE8+, with the same CSS, then you’re not coding it right. And in most cases, I would even add IE7 to that list.
As I’ve written before, if your audience (or potential audience, for a new project) has a large percentage of users on different versions of IE, your focus should be getting IE to work with the most efficient, maintainable, and hack-free code possible. If instead you wait until the end to add all your IE “fixes”, then you’re going to end up with a bloated and unmaintainable stylesheet (or multiple stylesheets, if you use external files).
Do It Only For IE6
So do what you need to do to get IE6 to work (which might mean an external stylesheet, a hack, or an IE6 html element class), but use good logical and best-practice CSS for the other browsers (including IE7 and IE8) and you should be able to get a virtually identical experience in all of them.
I think the Boilerplate does a great job of defaulting a ton of best practices techniques, but in this case it doesn’t. Its not best practice to have separate styles for IE8 and IE9. So if you do use the Boilerplate as your default, do yourself a favour and change the section on classing the html element so it looks like this:
<!--[if IE 6 ]> <html class="ie6"> <![endif]--> <!--[if (gt IE 6)|!(IE)]><!--> <html> <!--<![endif]-->
Your cross-browser CSS skills and website performance results will thank you for it.
Or you could just not support IE6 anymore ;)
I’ve been waiting for the day that I don’t need support IE6 in my systems … but this day not came yet …
unfortunately, so many developers still need make sites to IE6. It’s not our choice.
It’s always a choice, its a hard one. In most of my app’s for clients, we put a nice and pretty little warning on the site, “Your browser is no longer supported. Please visit Chrome, Internet Explorer, FireFox, or Mozilla, for a current browser.”
Its not ideal, i understand, but most likely your not designing for the 70+ yr old that still runs Windows 2000/ME.
Still, sometimes you need to differentiate FF and IE when there’s overflow involved, as one places the scrollbar inside the borderbox and the other outside.
Just do it when you need it.
Great Idea.
Only question is wouldn’t you have two <body>
tags in your HTML then? ex:
1. <!–[if lt IE 7 ]>
<body class=”ie6″>
<![endif]–>
2. <!–[if !(IE)]>
<!–>
<body>
<!–<![endif]–>
3.<body>
<!– the normal body tag that all other browsers will use –>
So if IE7-9 renders it would be
1. <body>
2. <body>
I could be wrong though. I think in theory a <div> would work better and then put condition comments at the end of the doc for the close as well.
do it:
<!--
change middle part to
[(gt IE 6)|!(IE)]
No, you’re not understanding how the “!IE” part works. When you say “If NOT IE”, you’re saying “all other browsers”. So the other browsers will see the body tag that’s inside the “Not IE” section.
If you look at it closely, you’ll see that the syntax is different. Instead of a single opening and closing comment on the whole thing, you have two different opening and closing comments. This hides it from IE but shows it to everyone else.
The “normal” body tag is the one inside the “NOT IE” section. There’s no other body tag declared after that.
I think you are wrong here. Conditional comments are only interpreted by IE. All other browsers reads it as a regular comments and ignores it. Google for it.
Believe me, I had the same impression you did at one time, because I didn’t look at it carefully enough. Test it out yourself.
Here’s an example:
Look at the two lines closely. You’ll see that the second line has two sets of comment tags, whereas the first line has only one set, wrapping the entire thing.
Every browser, except IE will see the
<body>tag in the second line, because the body tag is not commented out. But IE will not see the body tag on the second line, because (although it’s not commented out) the conditional tells IE not to look in that area.And this comment of yours actually helped me see that I made a mistake in my last code example in the article. I’ll have to correct that because the way it is now, it’s not allowing anything above IE6 to see a body tag. Thanks. :)
I think what Stjepan means is you don’t need the “!IE” part when you also have the “gt IE 6”.
1. “if IE 6” = only IE 6 will see it because IE parses that comment and shows it only if the user is on IE6. Non-IE browsers ignore the whole line because it is one comment.
2. “if gt IE 6” = Non-IE browsers will show the contents because the body tag is not actually in comments. IE6 won’t show it because it parses the line and sees it doesn’t apply. IE7+ does show it because it parses the line and sees it does apply.
The “!IE” is never considered by any of the browsers.
Oh, I realize that. I didn’t mean to imply that. I was just using “not IE” as a way to reference the last body tag.
It is a bit confusing to explain, because of the way it works (recognized by IE but not recognized by the other browsers).
I dropped IE6 support earlier this year and since then I have not used any type of browser-specific targeting. I’ve had a few problems that have cropped up in IE7, but finding a solution to it usually gives better code overall. If I did have a client request (read: pay for!) IE6 support, I think this is definitely the way to go.
I tend to agree with this advice. I am currently using Boilerplate for a project and realize that Paul’s method is overkill. Also — I ended up using a conditional style sheet anyway to prevent extra HTTP requests from going to compliant browsers. (due to lack of support for alpha transparency in background colors — I used a transparent png for IE8 and below )
I have also recently dropped support for IE6, it’s amazing how many edits I have cut down just by doing that. I also got the company that I work at to drop support for it too, the website testing team was very happy about it (we have a separate support team to test our sites). It was only taking up about 6% of our total browser share so it needed to go.
How can a company take their sites to the next level if they are tied down to a 9 year old browser? It’s the field of dreams methodology, if you build it they will come! Well “if you support it, they will use it”.
I can’t say that I find Paul’s solution very elegant, although it has its advantages. I disagree with the following though:
“As I’ve written before, if your audience (or potential audience, for a new project) has a large percentage of users on different versions of IE, your focus should be getting IE to work with the most efficient, maintainable, and hack-free code possible”
No. You should focus on getting it to work in standard browsers by writing standards-compliant code. This will ensure the broadest browser reach possible. Next, you focus on browsers that do not behave, such as IE6 and a bit of IE7. You start from good and then deviate to the bad, not the other way around. If hacks are required it does not matter whether you start with IE. The hacks are still needed. I do agree that testing for IE should happen early on, but developing for it: never.
Well, I’ll offer this challenge to any developer:
We’ll code the same design. I’ll code exclusively in IE6, and I’ll only check the other browsers at the end.
The other developer can use one of the modern browsers (Chrome, Firefox, etc.), then at the end, fix stuff for IE6 and IE7.
I guarantee that my code will be standards-compliant, and will have fewer hacks and workarounds than the other developer.
When I say you should start with IE6, I don’t mean you should use hacks, I mean you should develop with standards and best practices in mind, and get IE6 to work. Then, the result will be the best chance of attaining a more accurate cross-browser experience. If you start with Chrome or Firefox, and expect to go back and fix everything for IE, well, then prepare to use tons of hacks and workarounds.
I accept your challenge. ;)
Haha… Well, maybe I will regret this, but if you’re serious, let’s do it! Pick a publicly available free PSD like this one:
http://css-tricks.com/the-great-css-off-giveaway/
And we’ll spar it up…:)
I agree with Paul here.
Developers should code to the web standards. By coding to the web standards, you target the majority of browsers and future browser versions by coding correctly.
Then go back and fix the issues for browsers that have not followed those standards… IE6 and IE7.
I understand the idea of less server calls, but by separating the css files, it allows a quick delete of a file to drop support of an older browser, rather than scavenging through existing files unless the developer makes notes or by using naming standards within that file. Those ideas can work well when you are the primary developer, but when it comes to many hands touching the same files, those notes / naming standards will not last.
I have tried both ways, developing for IE and developing for the web standards. With my experiences, I have had better sucess with the standards.
I understand your concerns, and regarding later maintenance, you make a good point. It’s much easier to delete a file, but most times immediate performance is more important.
I do however take exception with your last statement, which implies that it’s not possible to code for IE and code for standards. That’s completely false. If I wanted to, I could create a layout that looks perfect in IE6, with 100% standard code, no hacks, nothing out of the ordinary, except the possibility that the code is less maintainable.
The only problem would be getting that same code to work in the other browsers. But on its own, it is not difficult to code for IE6 without hacks. And IE7 and above are very easy to code with standards, and get it to work cross-browser.
A late reply from me but I could not resist.
Louis, how can you say that if you wanted to, you
“could create a layout that looks perfect in IE6, with 100% standard code, no hacks, nothing out of the ordinary, except the possibility that the code is less maintainable.”
and then say that:
“The only problem would be getting that same code to work in the other browsers.”
Do we have different definitions of coding to standards? When you use that term, do you only mean that your code validates, or do you mean that it follows the standard? Because the other browser will, by and large, always work on code that follows the standards, because they themself follow that same standard. If your code ‘works’ in IE6 and not in the other browsers, chances are very, very slim that you follow the standards. Chances are in fact very great that you deviate from the standards in exactly the same way as Internet Explorer does, which is also the reason it displays you page exactly as you intended.
This to me is *the* reason you should code to the best (most compliant) browser out there and then test on the lesser gods; you don’t want to get sucked into following some path deviating from the standard because that is what your favourite browser does. You want to code to the way things are supposed to work (according to the W3C) and then fix the places that need fixing because popular browsers deviate from that behaviour.
Hey, Stijn,
That’s a good question, and on further reflection, I probably wasn’t correct in saying that it wouldn’t display properly in the other browsers. I think I was thinking more about how maintainable the code would be — but it would still use no hacks and only standard code (i.e it validates, no hacks, etc.)
To create a layout with IE6 without hacks is not impossible, nor is it extremely difficult. There are many ways to code a 3-column layout in CSS. You can use margins to separate your floats, but if the margins cause issues in IE, then you can try padding instead. That’s not a hack. That’s just an alternate way of thinking about the layout. If padding doesn’t work, you can use positioning, or maybe resort to faux columns, or another method that might require a few extra markup elements. So I suppose the code would be less standard because it has some extra markup, but that’s not really going to harm anything about the site except maintainability.
Also, this would not be the case in every IE6 layout. You can slice up a simple design for IE6 and make it work semantically and with zero hacks. It just depends on the complexity of the layout.
Finally, I’m not suggesting that a layout should look exactly the same in IE6 as it does in Chrome or FF3+. The basic code for IE6 would be standard and clean, with few or no hacks, and other enhancements would be provided for the other browser (PNGs, CSS3, etc).
So, to summarize, my comment was not entirely accurate: I believe a 100% standards-compliant website is possible in many cases with IE6, and that code will work in the other browsers too, but the other browser might also have some improved functionality.
Just view this site in IE6, and you’ll see that it looks pretty much the same, save for a few minor details like fonts and sidebar margins (which are barely noticeable).
I agree with you Louis.
We should develop with all browsers in mind, including IE6.
I test in all browsers when I code and I’ve found that this it’s the fastest way to work. No need to find or fix problems when you think you’re done. And it reduces almost all needs for browser specific hacks. If you know IE pitfalls, you should be able to avoid them.
But I don’t think that fixing IE6 in the end will result in more hacks or workarounds, although it’ll probably take a little more time.
And with that in mind, I accept the challenge as well. On either end. Or doing cross-browser testing when coding. :)
“I guarantee that my code will be standards-compliant, and will have fewer hacks and workarounds than the other developer.”
I don’t see how, and I don’t see how you can call your code standards-compliant when it has hacks. I also do not see how adding the hacks at the beginning is better than at the end.
I do see your point that when you include IE6, the surprise in the end is rather large, and that you will have to hack a lot of code. I just don’t see how it would be any less when you begin with IE6, since you will need the same amount of hacks anyhow, because IE6 misinterpretets a lot of standard code.
To each their own, but I really think your advise goes against common practice nowadays.
No, the hacks would not be the same, because early in development you would make a conscious effort to code things in such a way as to ensure that IE does not require hacks.
Remember, in CSS there is more than one way to skin a cat. If margins cause problems, you might be able to use padding instead. If floats don’t work, maybe positioning will. Of course, you would be reasonable with what you do, and not make it hard to maintain. But in many cases you can avoid a lot of unnecessary hacks with some good forethought.
On the other hand, if you commit to your entire layout without giving much thought to IE6 and IE7, then you’ll have no choice but to use hacks and IE-specific code, because the last thing you want to do at that point is rework large areas of markup and CSS.
This technique is contentious. Some people love it and others really dislike it. It’s fun. :)
Louis, your issues with it highlight a new and different problem that hasn’t really been addressed.. and hearing you explain it more starts to make your SmashingMag article make more sense. :)
Let me embolden what you said here, because it’s at the crux of your argument:
This is absolutely true.
When you are addressing IE’s inconsistencies, attempt to fix them without singling out IE in particular. In many cases, this is a matter of adding a
widthorheight.. or someoverflow:hidden. In general, being more explicit about how the element should appear helps IE6 and IE7 greatly.I’ve certainly come across IE8 edge cases where I need to throw something at it, but it doesn’t happen often. IE9’s need of targeted styles remains to be seen.
So I think the technique is still quite useful, but I have no problem reiterating what you’re saying. Trying to fix all inconsistencies with styles that all start with
.ie.. is troublesome fo sho.<3
Hey, Paul. Thanks for your input.
It certainly is interesting to hear different opinions on certain matters, so even if your inclusion of that technique in the Boilerlate is wrong, it’s still great to hear what people have to say, which is much more important and more effective than just sitting on our hands and never trying something new.
But you’re still the man, regardless of what I’ve said here, so keep up the good work, and thanks for all you do to help us become better developers.
but but…. why is it WRONG to include that?
I’m including jQuery and people tend to write absolutely atrocious code with that. I think including it along with documentation and some recommendations for usage is a lot more reasonable than ripping it out.
But the difference is, there is a right way to write jQuery code, whereas writing different CSS for IE8 and IE9 is wrong regardless of what is written.
Now, you have mentioned that you needed to target IE8 on the rare occasion, so in that case, you can just add the necessary conditional/class as needed. (As a side point, I would like to see an actual example where IE8 needed to be targeted in that way; not that I don’t believe you, but I just can’t believe that a non-forking cross-browser solution isn’t possible in all cases with IE8+)
I guess my main beef is that you’re an experienced developer, and you know what you’re doing, so it’s not going to harm your work if you have those classes in your default “just in case”. But most people that download that Boilerplate might incorrectly think “Oh, Paul’s cool, he thinks it’s perfectly fine to create CSS forking for all versions of IE!” when in fact you don’t think that at all.
And so you think if this technique wasn’t included, people wouldn’t be forking just as much, but with CSS hacks?
From here it seems the education aspect of this is discrete from the style targeting technique.
I really don’t know, to be honest.
I guess I’m a stickler for standing up for what is right, regardless of the actual results. I just think it sends the wrong message.
Maybe you’re right, maybe the amount of hacks and forking would be the same. I just can’t see your full version of the cc/classes helping the matter any.
It just boils down to whether or not the individual developer has enough experience to keep himself from using hacks where they aren’t necessary, regardless of what’s in their default template.
I know this is old, but you’re being absolutely obtuse… There are so many benefits to this method.
some bugs effect only ie7, and some bugs effect only ie8. This doesn’t mean we should write our css using poor form, but it gives us a lot of flexibility.
There is even a use here for Javascript – because you can test for ie classes instead of browser sniffing.
You think jQuery only checks for IE (not which version of IE) and tries to write its javascript in a way that will work on all IE’s cuz its the “right” thing to do?
haha.
Well, jQuery doesn’t “check for IE”, it checks for features, a lot of which aren’t available in IE, so it uses IE-specific fixes.
Nonetheless, I think at this stage I have no problem with using this method, I just didn’t agree with using it for targeting IE7 and IE8 because layout-wise, those browsers didn’t have too many problems. You could easily get a layout to look right in IE7 without any hacks or trickery.
But at this point, I think it’s fine to use these classes to target IE7 and IE8 for some edge cases. Which is why I later wrote this:
http://www.impressivewebs.com/ie7-ie8-css-hacks/
I just don’t agree with starting a project with the thinking “I can do whatever I want because I can create loads of IE-only hacks”. It just created bad code from the start that was hard to maintain.
I have to say that I admire Paul for his reflective analysis of his own boiler plate in light of your stance Louis but to imply his method is wrong is, well, a little rude. I believe that you may find your approach more correct than others but it seems to be based on the premise that all developers care little about standard code and as soon as they see an ie fix ditch cross-browser compliance completely. I argue that this is not the case and the majority of developers, especially those that appreciate and utilise a well structured boilerplate like Paul’s, strive for standards compliant code and that there are very few ie specific ‘hacks’ required. The fix in the body (or html tag) allows for a few quick lines that address these small issues left by what is usually a very high standard of code. I think your downfall in your case is the assumptions of the skills and standards of the developers out there and the great example the boilerplate gives in how to achieve this. In summary you are on the same side here, one just has a better respect for the developer’s own standards.
P.S. We have updated the boilerplate to use:
Which taking bot harguments on board probably does not need teh ie8 or ie9 classes but we review this on a use case basis. If we need it we use it – hence the popularity of this method.
If Firefox allowed conditional comments, would you also include 6 new lines to account for all of its versions, too? Certainly not.
The problem is that even standards proponents tend to inadvertently lean towards the “ditch IE” attitude. Paul does not favor “ditching” IE. I know that. But when he puts out a default template as popular as the Boilerplate, he has to understand that many people could assume that he doesn’t care about IE performance, or doesn’t care about maintainability of the code associated with IE.
This solution, when it includes IE7 and above, does things backwards. You’re telling your code to “degrade” for IE when there’s problems, when instead you should be telling your code to progressively enhance.
Standard code that works in every browser (except IE6) is very possible in almost all circumstances. This solution is overkill, and I cannot agree with its inclusion in a default template. It’s really the opposite of “best practice”.
Nonetheless, the Boilerplate is 1000x better than anything I could personally produce, and I think Paul and Divya have done a fantastic job on it.
Neither do I favour or promote ‘the ditch IE’ approach.
I favour progressive enhancement and crucially on non-critical elements of a site.
I do however choose to not build in IE6 first – which is where we differ.
I struggle to adopt that this method equates to not caring about performance (boilerplate explains this better than I).
I disagree it promotes an anti-IE approach. A universal IE6 stylesheet would be more effective to achieve this.
Conditional statements allow for developers to fix inconsistencies in non-standard compliant browsers. IE have the market share here.
I think that their use for this purpose has little to do with degradation (or enhancement).
Best-practice is definitely subjective, hence the debate, but I cant help but feel your case is only ever going to sound more and more out-of-date as browsers improve and users upgrade.
We don’t film in black and white then paint over in colour.
In addition … I do take on board that that the extent of conditional statements by default is likely overkill and through experience IE6 and IE7 would be our main if not sole ‘offenders’ – I don’t think it promotes a wrong way of working though.
That’s fine, I see where you’re coming from. It’s a bit of a subjective issue anyhow, because if your audience is mainly non-IE (as in the web design industry) then I would have no problem using that technique.
Oh, and BTW — there’s no such thing as a “standards-compliant browser”. :)
Unfortunately I continue to have to disagree in principal with you as I believe it still to be a perfectly acceptable way of working regardless of the audiences browsers.
RE: Standards compliant browsers – that’s just being pernickety!
*Browsers built with standards in mind/ Non-proprietary / interoperable / recent versions of / doing it better than others / you probably knew what I meant.
Or you could bring this even further:
-[if lt IE 7]>
<!--
i mean
<body class="ie ie6 lte9 lte8 lte7">
<body> <!--
a edit-function would be rly nice…!
I’m not sure what you’re trying to include here, Alexander. If you can submit a corrected version, I’ll delete these other comments. Thanks.
If you only need to target IE-6 and IE-7 you can do it with pure css, with no conditional comment.
Except now you have horrible, unmaintainable CSS. You’ll almost certainly end up putting
html > body > .someclassin the middle of legitimate styles, without an explanation comment, then promptly forget about it.You really don’t need to double comment the “other browser” tags:
<!--[if !(IE)]><!--> <body> <!--<![endif]-->This:
<![if !IE]> <body> <![endif]>will work just as well – IE doesn’t see the body tag, all other browsers ignore the conditionals even if they’re not commented. Microsoft calls them downlevel-revealed conditional comments. With the comments they’re “downlevel-hidden”.
Yes, technically you’re correct, but that version of the conditional doesn’t validate, as explained in this article on SitePoint under the heading “Downlevel-revealed Conditional Comments”.
So you need to use full version which has two full comments instead of that somewhat abbreviated version.
Hi guys, i’m usually more a comments reader but this a topic I need to join ;)
I was very impressed when I first stumbled across the boilerplate, and especially when I looked at the conditional ie body tag comments, thanks Paul by the way for this amazing collection of best practices.
If I’m in control of the css for a new project all on my own (no other frontend guys) my standard way is to have conditionals that refer to specific stylesheet-files, let’s say ie6.css and ie7.css.
But the real help of the “body-comment-class” – technique for me drops in and shines when i’m building a big/complex site together with other frontend-developers. Then I’m usually the guy who creates the base structure and styling as well as some kind of html/css that could be seen as modules. These modules are targeted by one certain selector in front of the desired elements (e.g. .cnt-module-gallery … li a ) bla bla …
As the backend joins a list of multiple css-files into one single bigger one to save http-requests, my co-workers can be create/edit css for certain modules in their own independent files. Yes we use subversioning, but having css split across file makes sense if they only target specific modules (that might get changed / swapped for alternative versions and so on).
Ok long story short, when I’m working together with other people on one big project I supply them kind of a css-preset-file with comments and helpers as well as predefined sections, e.g. where to put font-related stuff / where to put structural stuff which makes it way easier to find unneeded / repetitive code afterwards. – One of these sections is for IE6/7 exceptions, as i dont’ want the other developers to touch my conditional stylesheets which are only used for structural fixes and once working won’t need to be edited my anyone else than the guy who’s responsible for all the basic page-stylings.
To keep this .ie6 / .ie7 … some-slector stuff in predefines sections of the .module-xyz.css files makes it really easy afterwards to get an quick overview if and how your co-workers solved ie related problems, keeps the small fixes seperated from the important stuff, and if you want /need to optimize the css-amount before going live a futher bit, it’s easy to check the addition files and move the ie-fixes from there to your ie6.css / ie7.css files.
Maybe that’s not important stuff for many people but I just needed to share my thoughts. I see this technique more as a workflow optimization for team-development vs. single-guy-development instead of just a different way to target IE-Browsers. I hope my explanations were understandable as I’m not a native speaker ;)
Great article. I also don’t like the fact that when you use all CSS in 1 file and you need to use CSS3PIE .htc script or some other script for CSS3 support in older browsers. The script is then download every time for every browser, wich is totaly unnecessary.
Some really good thinking in here.
Do you think this IE first approach would be compatible with responsive design, that adapts to not only pixels but screen DPI’s? There the approach is very often ‘mobile first’. It would be great to hear your thougts on this.
Yeah, in the case of Responsive design (which was not yet popularized when I first wrote this), the technique of checking IE early, or getting the basic layout working first in IE, might be troublesome.
Things have changed a lot since I wrote this, though, especially since IE6/7 usage is now quite low in most niches. I’m not yet convinced on the “mobile first” approach either. But it’s definitely an option.