While The Wife is away on a business trip, I’ve reverted to form, working 14 hours at a stretch to finish a rather attractive site I hope to take live within the week. Like all recent jobs, this one uses pure and somewhat sophisticated CSS layout, and it looks and works gorgeously except in Browsers B and A.
Browser B usually supports web standards well, but in this case replaced elements that float left aren’t floating left and CSS rollovers aren’t rolling over.
A is the world’s most-used browser, and it handles the front page correctly. But when the same elements are used deeper in the site, Browser A inserts a false carriage return above the text that sits to the right of the floated, replaced element. It’s a small thing, but small things are everything.
So I need to rethink the CSS and then redo the markup throughout. Why redo the markup? Well, for instance, I might be using a span to contain alternative text that is hidden from CSS-capable browsers but visible in non-CSS environments. That span might be set to display:block. And it might be the source of Browser B’s float flub. If I rewrite the CSS so that the alternative text is contained within the anchor tag, I’ll need to change all the XHTML accordingly.
The task will take most of the day. If it solves Browser B’s problem, it might also fix A. Of course it might fix one and not the other. Or it could fix neither.
Everything I’m doing in this troublesome part of the layout could be handled with table cells and traditional JavaScript rollovers and it would work everywhere. (By everywhere, of course I mean in popular browsers with default settings.) Not only would it work “everywhere,” it would also take much less time to code. Because I and you and everyone knows how to do it that way, whereas with complex layouts, The CSS Way is still a mostly unexplored continent.
So I ask myself, if the old-school no-brainer approach works reliably and requires no experimentation, why do I and so many others insist on doing things the new way?
And the answer, I remind myself, is that the new way is better for people who use sites and better for people who maintain them.
It’s better for users because, once I’ve finally solved my design problems, every page of the site will load faster (as the markup is minimal) and the content will be available to more browsers and devices (as the markup is semantic).
And it’s better for those who’ll maintain the site because they will never have to muck around with presentational elements; they’ll just be adding to or replacing structurally formatted text. (This is true even when the site is powered by content management software. Simple is simple.)
Every time I design a site in CSS I hit the same wall where the logic works, the CSS and XHTML validate, and the display is perfect except in Browser X, where it is so bad I need to start over. Every time I hit that wall I curse Browser X and myself and the client and the W3C and Ben and J-Lo, just because.
Then I get back to work.
More highlights and back orders may be found in our Essentials Department.