CSS survival guide (developer addition)
When you are a developer working with CSS on “as needed” bases, you have to be prepared for some pain and frustration. Don’t get me wrong, I love CSS – and what not to love? It makes your HTML code clean and light-weight, pages load faster and all formatting logic neatly separated from presentation markup. Beautiful! But I hate it, too. There are two major problems with CSS: it is not intuitive and every browser has its own parser doing job “better” (differently) than others. Practically, it means that when working on CSS you have to fire up 3-4 different browsers and test every line as you go. If you miss the point where everything broke apart, rarely you can look at the lines you’ve just written and say “oh, I see, how could I miss this one”. Most likely, any of those lines can be a bomb waiting for happy camper to step on it and you’ll have to roll back to the last working version and start over. At least, this is what I used to do. Eventually I got tired and changed approach, now I make it work in one browser and later fix problems in the other(s).
I used to work in all Microsoft shop and IE was our primary focus, and then we would have for every project separate CSS file for Netscape and everybody was complaining about “bugs” in NN. Our days, picture reversed for a most part - now people are frustrated with IE “bugs”. So today I have separate CSS file for IE, just to be fashionable. The whole point having separate file is that you can put there all your fixes and override styles for particular browser. So, you would use something like: if IE – add another style sheet to the header. Thanks to cascading nature of CSS, all styles in this second CSS file would override their twins in the first one. For example, if you have “p: color red;” in the main style sheet and “p: color green;” in the style you attach only if browser is IE, then for FireFox you will have paragraphs in red and for IE – in green. In today’s exercise I will style horizontal menu in Gecko compliant browsers (FireFox and Co.) and then fix it for IE.
Now, with this aside, let’s get started with clear understanding what elements we going to style and how to address them in the style sheet. Typically, you want to have composite link buttons so that you can style center, left and right corners separately (to make possible create rounded corners, shades and other effects). And the whole surface should be clickable. That dictates certain level of complexity. Here what HTML for a list item looks like:
<li><a href="#"><span>Top One</span></a></li>
And this is a box model we are going to deal with:
Seems fairly simple, if CSS was a programming language with common interpreter it would be a walk in the park. But it’s not, so it is more like a tightrope walking instead. The result we are after you can preview here (for IE) and here (for FF&Co). Nothing special, clean and simple – but you can let your imagination run wild if you want to, this design gives you access to most of the functionality you ever going to need. And don’t worry; in the end we will combine both together in cross-browser solution. Here how we going to style list so that selected menu item have rounded corners:
#navmenu .current a {background : #a9bc52 url(tabl.gif) no-repeat left top;}
#navmenu .current span {background : #a9bc52 url(tabr.gif) no-repeat right top;}
[to be continued...]
