I was having a conversation with someone who was developing a site and who had it looking good in some browsers and not others. She had markup like this:
<div id="before-nav"></div> <nav>…</nav> <div id="before-footer"></div> <footer>…</footer>
with the empty
<div>s being used to hold the top half of an image of some rounded corners. The page’s document landmarks needed rounded corners, and my friend was using images rather than CSS3
border-radius so it would work in IE<9.
Her problem was lining up the top half of the background effect with the bottom half, as they’re behind two separate elements and browsers have inconsistent browser stylesheets. So to get it to line up she was going to reset loads of elements and potentially resort to CSS hacks.
The trouble with this is that you’re then building hacks on top of hacks. Using completely empty
<div>s for presentational purposes is already hacky, and it means that Opera, Firefox, Safari, Chrome and IE9 get markup and images they don’t need, as they could just use
It might seem obvious, and the “build for good browsers, then hack for bad browsers” methodology has been around for a while, but let me gently remind you: don’t penalise the good guys. In Web design, unlike the real world, the polluter pays.
So, my friend should have designed her site with no extra unsemantic thingummies, and used
border-radius to achieve her design effect. (If she were using more experimental CSS3 properties, she’d neeed a cross-browser future-proof vendor-prefix stack.)
Once this is tested and lovely in Opera, Firefox, Safari, Chrome and IE9, she can add one line into her CSS, courtesy of CSS3Pie, and her CSS rounded corners will work everywhere, but only the naughty browsers download the extra stuff.
This works nicely for CSS. For HTML5 APIs, there are all the HTML5 Polyfills. Sure, there are edge-cases and undetectables, but as a general methodology, the polluter-pays approach will speed up your development and leave you with clearner, less-hacky and therefore more maintainable code.