Cross-Browser CSS Development Workflow:
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 Nicholas 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.
Related posts:
