A couple of weeks ago when writing about css vs tables I mentioned it was a myth that cross browser css was hard to implement. I thought I’d take a deeper look into cross browser css today and offer some ideas and tips to make cross browser development easier.
Browser Rendering Engines
Some browsers share rendering engines . Safari and Chrome both use the WebKit rendering engine for example, so if your site looks good in one, odds are it will look good in the other as well. The main rendering engines you’ll likely be concerned with are:
- Gecko – Firefox, Flock, Camino
- WebKit – Safari, Chrome
- Trident – Internet Explorer
- Presto – Opera
- KHTML – Knoqueror
Get a feel for how well a rendering engine adheres to css and realize that if your code works in Firefox it likely will work in Camino as well. Here are some charts that compare different browsers and their compliance with css. Be aware they may not be completely up to date.
- Comparison of web browsers
- CSS contents and browser compatibility
- CSS Browser Support (IPhone, IE8, IE7 Compliance Mode, FF 3.5 Beta & Safari 4 Beta Included)
Use a Reset So Everyone is on the Same Page
One of the main cross browser issues is that each browser or rendering engine uses different default values. For example when it comes to lists one browser might use padding to indent the list while another might use margin to set that same indent.
If you look at the reset files you’ll notice they cover some elements you probably never use. If you’re up for it you can write your own reset file that includes only those html elements you’re likely to use. Developing your own reset can also be a good way to learn more about the default values different browsers use.
Choose Your Browser
A quick point to consider is which browsers and versions you’ll develop for. IE6 is notoriously bad at rendering quite a few things. Should you do the extra work to develop your site for it? That depends on the site and the expected audience.
Remember you don’t have to develop your site for every browser that exists. Develop for the browsers that will realistically be used to view the site.
Develop to Web Standards and Your Own Standards
Because Internet Explorer is the most commonly used browser many think they should develop for it first. However, IE is also the browser that gets the most things wrong so this isn’t the best strategy. It’s generally best to develop to web standards and then tweak for IE.
By developing to standards you lay the groundwork for a good page and then you can tweak as appropriate where some browsers get it wrong. You’ll find you spend much less time on specific browser tweaks this way than if you develop first for IE.
In addition to web standards, develop to your own standards. As you build more websites you’ll naturally begin to reuse the same code. Every 2 column layout or 3 column layout I create starts with the same basic html and css. Over time I’ve learned where the potential problems might be and I’ve developed code that works well across browsers.
Build yourself a library of layouts that work cross browser and continue to use and improve them.
Tweak for Uncooperative Browsers (I mean you IE)
It’s inevitable that a few things won’t work quite as expected in every browser and usually that every browser will be Internet Explorer. IE isn’t nearly as bad as most people think when it comes to rendering css. Yes you’ll likely mutter “IE sucks” under your breath or scream it our loud at times, but it really isn’t as hard to deal with as you might think.
Many web developers, including myself consider conditional comments as the best way to deal with the quirks of IE. Only IE reads conditional comments. All other browsers ignore them so it’s a great way to send IE-specific code to IE. You add them to the head of your document like so:
As your skills improve you’ll find you only need to adjust a few things for IE. Maybe one div is displaying further from the right edge than you intended due to the double float issue.
One solution is to reduce the left margin on the div. By using conditional comments you can tell IE to use the reduced margin, while all other browsers use the original margin.
You can create an IE specific stylesheet (style-ie.css?) and then load that css file for IE through conditional comments. Even better you can target specific versions of IE so you can have a style-ie.css and a style-ie6.css, etc.
Experiment and Play
In between projects create a file and just play. Experiment with css borders and see what happens when you set different properties. Build a house with css if you’re up for the challenge. The idea is to experiment and play with the goal of learning to better control your tools.
When I was first learning css I set myself a challenge to learn something new on every site. With each site my skillset grew and I had more tools at my command. On a slow day I would open a new file and just see what I could do with css and what I could create.
If you do the same your skills will improve and you’ll soon be developing sites quicker that require less browser specific code to display the same across different browsers. There’s no replacement for experience.
When you’re first starting out developing all css sites it can be frustrating at times and you might swear that your site will never work cross browser. Please believe me when I say that thought will only be temporary if you develop a good approach to building sites.
Understand the major differences in browsers, code to standards, and tweak. In between sites experiment and play to improve your skills.
Cross browser development is not as hard as it seems. The key is to understand how you develop and where the potential problems might be. As you understand the typical problems that arise in your particular layouts, work to find solutions for these problems and look to improve your basic layout code.
Download a free sample from my book, Design Fundamentals.