Most good developers by now accept the fact that pixel-perfect cross-browser CSS is not only unnecessary, but also totally impossible.
Of course, when we speak of the challenge of “cross-browser” CSS, we’re really saying “How can I make this work in Internet Explorer versions 6-8?” — because those are really the most problematic browsers.
Although I’ve written before about cross-browser CSS, and I still stand by just about every word in that article, I thought I’d reiterate my feelings on this subject by providing what I feel is the best workflow for getting your CSS to be as efficient, hack-free, and maintainable as possible while providing as similar an experience in all supported browsers.
Keep in mind that the recommendations here would likely only apply if you are developing projects with a high number of users on older versions of Internet Explorer.
1. Reset or Normalize Your CSS
There are people that have done a lot of work that’s contributed to discovering and dealing with the differences in how browsers style various elements. Take advantage of the work of those ones.
Use Eric Meyer’s most recent CSS reset. If you’re hesitant to use something that the author himself has labelled “a work in progress” and after which he says “this is not a final version”, you can use his most stable version. You also have the option to use HTML5 Doctor’s reset, which evidently is similar to Meyer’s latest.
You can use what is likely becoming (if not already) the new hotness in CSS resets: Normalize.css by Nicolas Gallagher and Jonathan Neal.
I haven’t used Normalize.css yet but, from my brief assessment of it, it seems to be exactly what a CSS reset should have been all along. After all, why does a CSS reset zero out the padding and margins on elements that don’t ever start with padding or margins in any browser?
For more info on CSS resets, you can check out Michael Tuck’s excellent three-part series on Six Revisions:
2. Get Your Basic Layout Working In IE
The worst thing you can do for the performance and maintainability of a website is to check how it looks in older versions of IE only after finishing coding nearly your entire design. This is especially true if you are designing a website or app that will have a high percentage of users on older version of IE.
Before you start adding complex positioning, negative margins, z-index tricks, or other advanced layout techniques, take an early look at your layout in IE. Throw some mock borders on the container or other primary page elements, and make sure it’s all looking relatively the same as in modern browsers.
Your basic layout should work flawlessly in all browsers
If you see any major problems in the layout in IE, then you may have to rethink some choices you’ve made. Maybe use padding or positioning instead of margins. Maybe avoid overusing floats. Or maybe add overflow: hidden or give the element layout, to ensure backgrounds appear as expected.
Yes, it’s true, you could wait until much later in development and if there are any problems you could use some IE-specific CSS or hacks to fix those issues. But then you’ll have extra unnecessary CSS that will make your stylesheet larger, slower, and harder to maintain.
Thus, by nipping any IE problems in the bud as early as possible, you may very well avoid nearly all IE-specific CSS.
3. Finish Coding and Check IE Again
Once you’ve ensured that the basic layout works the same in all desired browsers, add the meat to the bones. Slice up any images, add your CSS3 enhancements, polyfill where it doesn’t hurt performance, and finally, check older versions of IE again.
At this point, the problems should be minimal. In most cases, you should be able to fix them without hacks or workarounds. Your code will be clean and you won’t have dozens of lines of IE-only code that will be harder and harder to track down as the project grows.
But what if the deadline is approaching, and you’ve still got a few seemingly unfixable problems in IE?
4. Deadline Approaches, Use IE-Only CSS
If the deadline for the project is approaching and, despite your best efforts (as described above), you’ve still got some significant problems in IE, then go ahead and add a few IE-only styles to get things looking right.
Since you’ve done everything you could throughout the project, it could be that either a lesser-known IE CSS bug has appeared, or else you’ve run into something that you didn’t have as much experience in.
Using a hack or similar workaround would also be advisable for any maintenance or subsequent updates that are under a time constraint. But that’s not the end of your fight against the IE-only code.
5. Push to Production, Keep Working on IE Problems
Just because the site or app is live, doesn’t mean you should stop maintaining it and ensuring the code is as efficient as possible. Of course, this may go beyond your current budget and time limitations. But since some of the IE-only code may have been added because of time constraints, it would be a good idea to try to fix those problems using standard code.
You might have to rearrange something in the markup, or completely rethink the way you’re writing that particular part of your CSS — but if you can avoid any IE-only code, you will ensure the CSS is as clean and readable as possible. And most importantly, you won’t be giving the slowest browsers the most code.
Conclusion
This workflow won’t be perfect for everyone, and it certainly won’t be the most efficient method if you’re developing sites or apps that don’t have much of an IE-based audience. But if IE users are a large part of the site’s target or present audience, then this workflow could potentially help you avoid using too many IE-only exceptions, and you’ll probably also gain a much better understanding of how older browsers handle various CSS techniques.
Excellent advice. Speaking for myself, when I start doing my initial design breakdown work, I consistently check things in several browsers as I develop my code, including IE7/8. This may slow the development process somewhat, but I also have far fewer issues to resolve when all is said and done – I’d much rather fix problems as I am actually developing, as opposed to tackling them all at the very end. There are the occasional sites that give me appearance problems in IE, and I also never use IE specific CSS, but I have yet to run across a design that can’t be made to look and function nearly the same as it does in other browsers. I accept that IE will have issues and simply find workarounds that don’t rely on browser-specific coding.
I don’t think it’s accurate or fair to blame IE alone. Cross-browser means a lot more to me: how well do the latest flavor of the Big5 tackle the HTML5 & CCS3, and, even more, how well their mobile counterparts do with my code.
One example: CSS3 rounded corners. Another one: page-wide gradients. And another one: fixed backgrounds.
From my experience, even the well regarded UAs can choke on what it should be simple stuff. Enthusiasts have served too well the cause of HTML5 and CSS3, and thus some UAs have engaged in a madness of pointless innovation: 3D, NaCl. If I wanted this, a desktop app with Internet sockets would be far more adequate. And it would be called by its right name.
One other aspect: the new range of skewed and weird solutions relying on :before and :after to bypass a normal and healthy markup only to squeeze a bit of false originality.
My absolutely personal take on this: after some pondering time and a few trials, my new goal is to forget about most of the new fancy in HTML5 or CSS3, and rely more on plain old HTML and CSS. Sure, new HTML5 semantics, a few CSS3 here and there, but nothing too crazy.
@IT Mitică: Absolutely, agree with you! Recently we’ve tried to analyze the problem from the similar points of view (“Cross-browser PSD to HTML conversion – How compatible should it be with the advent of mobile Web?”, http://www.htmlcut.com/blog/cross-browser-psd-to-html-conversion.html ) and the answer is very close to yours : 1). there is no sigle recipe for all tasks and target audinces; 2). “…wisely separate the husk from the grain and the hype from the hope considering the latest buzz about new tendencies in order to make a sound decision.” Thank you.
Thanks for this. I’m going to give the normalize.css a go. Also some good links here I know I’ll be coming back to check on when I need help with any fixes.
I just picked up the habit of including a set of CSS reset style definitions when I started modifying the default WordPress theme. I’m a bit more confident to continue with that now that I see it here. Also, problematic IE is problematic :) Thanks for sharing!
I’m clad that most of the popular CMS’s do the resetting for you
Eric Meyer’s css reset has been a staple on my style sheets from day 1.
I haven;t played with normailze yet, but look forward to seeing it in action.
This has been a huge part of my designing mantra: start with a functional and appealing layout (targeting IE), then add the css3 transitions, then add the javascript to make the transitions work in IE.
Rinse. Repeat.
Great stuff, thanks!
Great article! I’ve invested pretty much time into setting up my own reset/normalize stylesheets recently and also wrote about it: http://www.css3files.com/2011/09/21/the-long-way-to-a-reset-stylesheet. It took me quite long to decide whether I will follow the normalize or reset course, but in end I choose to get the best of both worlds. reset.css was too pervasive for me and normalize.css too extensive.
Ive actually never needed to use Eric’s reset because I was introduced to YUI a few users ago. Every project I work on employs at least the YUI reset and fonts. Grids is also amazing. I’ve built WordPress and Drupal themes based on YUI… Don’t know what I’d do without YUI.
One disadvantage of normalize.css over other reset sheets is that you’ll end up typing more code in elements. The margins and paddings of some elements are not set to zero and that can be frustrating sometimes.
An advantage over the other reset sheets is that you don’t have to re-type the correct margins and paddings for a
<ul>in a content div. This is especially a big advantage in CMS’s, because the users can use any element without having to test it.For the rest; normalize.css is awesome and I definitely recommend it!
That’s exactly why I use YUI. I’m much rather write exactly what rules are needed… I don’t like assumptions. That’s when you get into IE and even Firefox trouble.
I’d*
Great article I always test out my site on IE tester. So far I dont have problems with IE8 or 9 but IE 7 I notice has problems with a lot of relative and absolute positioning.
Thanks for writing on this subject. Many a time the differences between the versions of IE, Firefox and so on have slowed down a web design project in order to chase down and fix the differences from one Browser to another.