Sometimes, A House of Cards

Two hours go by and I still couldn’t figure out why the navigation links weren’t clickable in IE/Mac. This was one of those times I find myself cursing, putting off lunch and cranking Journey until I figure it out.
Process of elimination got me nowhere. Remove one rule, they work — but the layout is off. Remove the same rule, along with 10 others and they don’t work — but the layout remains stable. Repeat.
Another hour passes. Journey’s Greatest Hits is on shuffle (there is something about the combination of Steve Perry and CSS. I can’t quite put my finger on it). Aha! If I remove position: relative; from the element that follows the navigation — everything works. Of course.
The preceding scenario doesn’t happen every day, but when it does, it’s a roller-coaster ride of sheer anger, followed by the greatest elation one could possibly receive from writing code. Don’t take this the wrong way — I love CSS. I couldn’t get by without it, but on those rare (or sometimes not-so-rare) occurrences when a complex CSS layout becomes a “house of cards”, it can sometimes be enough to scare you into realizing, “whoa, I just spent three hours trying to figure out this one small problem for one browser”.
You may be wondering about the specifics of my aforementioned troubles. But I couldn’t begin to document the 4,723 steps it took me to get to where I was and the equal number of steps to get back only to fix the problem with a single rule deletion. *Sigh*.
Doug waxed poetic on this subject back in January. That it’s wise to factor in extra time when planning for cross-browser CSS debugging.
What’s amazing to me is that changing one rule, that by all obvious appearances has nothing to do with the problem, can sometimes be all it takes to fix the entire issue. The lesson here? When something doesn’t work, try the obvious — but don’t forget the unobvious.


  1. Dave S. says:

    I’ve taken to relying on Undo in a big way.
    That is, delete this huge-ass chunk of CSS. Does the problem still occur? (ignoring, of course, all new problems induced by that missing CSS) If yes – Undo, then delete another huge-ass chunk. If no – Undo, then delete another smaller-ass chunk.
    So on and so on. Process of elimination until I can figure out which line is causing it. The fix is usually obvious by that point.
    One thing I’ve definitely noticed is that debugging CSS requires mental commitment. If I’m going in prepared to only spend a couple of minutes half-heartedly looking, I generally won’t solve it. If I go in with grim determination to fix the bastard once and for all, I get it far sooner than I expect.
    Your results may vary.

  2. Radley Smith says:

    IE/Mac always seems to have the weirdest bugs, such as the overflow: auto bug I discovered. Maybe some day we won’t have to do this :)

  3. Jack says:

    The worst part is that it’s more or less a thankless job at times. All those hours of hair pulling and most users just go about their daily lives like nothing ever happened.

  4. Nestor says:

    Wouldnt it be great to build a list of all the bugs everyone finds? Something like a community effort… An “Open Source” css bug list!

  5. Agreed with 100% of what Dave says in the first comment. I’ve also found that’s often a good way to debug a problem with CSS — or if nothing else, at least a way to isolate where the problem lies, so you can try alternatives. It’s sort of like playing Battleship, but you can target half the board at once, then continue halving your targets until you zero in on the bugger. Much faster then trying one thing at a time.
    The commitment to solve the problem is also key. It takes some patience and determination. But commiting to the problem like that (removing whole chunks of code at a time) can often shorten the actual time it takes to solve it.

  6. soxiam says:

    True dat. Also, please take a friendly advice from this moron and be sure to check for the ending semi-colon in your CSS declarations if nothing seems to work even after *hours* of troubleshooting.

  7. Keith says:

    The “undo” method Dave talks about is useful for lots of things. Process of elimination is something I’ve found almost as useful as trial and error.
    For real dough.

  8. My left hand is cramped from “Command-Z” fest that took place earlier :-).
    Undo is a savior, and I’ll agree with Dave as well — it takes commitment (and some creative tunes) to dig deep and solve some of this stuff. But the small victory that’s won in the end makes it worthwhile. The more of these problems you run into, the larger catalog of solutions you begin to rack up as well.
    Doug – “C9″ :)

  9. Jeramey says:

    I’ve gotten to the point at times where I would literally start to rebuild a test site line by line of code to finally get it to work again. I’ll end up finding that it was some typo with not capitalizing a word or something.
    I’m completely with you on your frustration and elation and I have no idea what a quick fix for that problem would be.

  10. Bruce says:

    A good idea for those who are suggesting you check your syntax is to get an editor which supports code hilighting and rcognises which CSS properties are real and which are made up/typos. HTMLKit does the hilighting and is the one I use but it doesn’t do CSS property recognition. (Perhaps there’s a plugin for it).
    Another good tip is to CSS-validate your code when it’s not working right, because that will pick up mistyped properties.
    Of course, all of that is irrelevant when you have valid CSS which a single browser is having troubles with.
    Anyway, can’t complain, that’s why people hire us, because it isn’t as easy as it looks.

  11. Mike P. says:

    Yep, feel your pain Dan; oh, and the glory, and glad I’m not the only one who’s thought ‘house of cards’ (tho’ still not too happy about that thought).

  12. Nestor wrote:
    “Wouldnt it be great to build a list of all the bugs everyone finds? Something like a community effort. An Open Source css bug list!”
    Me and Jon Stanley are currently in the process of setting up a wiki for exactly this purpose. We are both pretty busy at the moment, but as soon as we find the time, we will ask authors to submit or allow usage of already written material to have some content to start with and open up the wiki for everyone who wants to help out.
    We know there is the the css-discuss wiki, but it doesn’t really touch upon this issue.

  13. The link is and not .com, sorry for the confusion.

  14. Web Standards made cross browser testing and coding irrelevant. Long live cross browser coding!
    Has anyone else noticed this trend? Part of the promise of Web Standards is write once, and rock and roll.
    Instead, lately I find myself more and more working out issues, just like Dan talks about, for specific browsers. It’s almost like table layouts and 1996 again.
    I think this has come more into play as CSS techniques have become more sophisticated. The lowest forms of CSS work find across browsers. Do something “cutting-edge” and you have a lot of work ahead of you.
    We’ve exchanged one set of problems for another. Have we gained anything in the process? I think we have, we’re fairly aware of the benefits of Web Standards. But we have a LOOOONG way to go, and I don’t see a whole heck of a lot of light at the end of the tunnel.
    Just my .02

  15. cm says:

    Thank you for this post, Dan. It is very nice to know that even you (and by the looks of it some of the other commenters here) go through what I go through.
    The process of elimination can be a tedious exercise, and sometimes I question wheter I’m going about it all wrong or if its just my inexperience that prevents me from just “being able to figure it out.”
    Knowing that you’ve done the same thing sets my mind at ease.
    And if anyone can tell me why the hover state in my navigation bar doesn’t work in Firefox, I’d be appreciative. Thanks.

  16. AllSpiritsEve says:

    You know, I always remembered those table-layout days as being pretty simple compared to the headaches I get from css nowadays… but then I started to work on a table layout for accessibility purposes, and realized that it is so much more work than our css problems. Things like padding that won’t leave unless you put cellpadding=”0″ and cellspacing=”0″ really make stuff hard, and I am so glad we are past that now.

  17. Andrew says:

    I’ve always found that putting code in comments, rather than deleting/undoing, is much safer, mainly ’cause I always seem to end up getting in to a position where I can’t undo again (maybe that’s just me?). At least with comments I can just remove them.
    But the concept is the same, I guess. One big process of elimination. I have in the past ended up commenting out an entire style sheet, working my way in from the edges until I find the offending rule.
    I always put the comments in pairs too, rather than just at the start/end of the code block, ie. /* * / [code] /* */. This means that with one simple space character, I can turn the whole lot on and off - remove it from the starting comment block, and the code is back where I wanted it.

  18. web says:

    When I get really frustrated, I try to remember that every second of time I spend on bug fixes I know that CSS will save me 4x that in the long run.
    Music is key.
    Sometimes while working on a CSS problem I can swear I hear Eddie Vedder telling me [begin singing] .. “Checcckkkkkk the padding on the containing divvvvvvv” .. [/end horrible singing]
    Music, if nothing else, keeps my fist from going through the monitor.

  19. Bo Salisbury says:

    Back before you folks were probably born, I remember seeing a handmade poster on a telephone pole in East Los Angeles, advertising the first area show of a new supergroup, Journey, playing at the Whiskey-A-Go-Go on Sunset Blvd. My friends and I were big fans of Neal Schon and Aynsley Dunbar (from the Mothers), so we were practically the first in line. What a show that was! Neil and Aynsley were joined by Ross Valory, Gregg Rolie and a rhythm guitarist / vocalist named George Tickner, who later went on to become a physician or something.
    Anyways, I’m an old duffer, so when I’m having trouble I have to shift to chorale music or some ambient stuff (Aphex Twin) or some older Miles Davis or absolute silence. When things are going well, then it’s happy punk or trance or the 77′s.
    Where would design be without music?

  20. Jeremy Boggs says:

    I literally found out about CSS in January in a class I’m taking in grad school, Creating History in New Media. CSS is amazing stuff, and I’m so thankful that I’ve found it, but the countless hours doing things that Dan is talking about here is not unlike reading about 6 books a week (which is fairly typical in a history grad program, my experience in my MA program anyways). I actually messed around with a problem for the past 4 days for one of my assignments, which I haven’t completely solved.
    Because it’s so new for all of us in class, and because we’re all historians in the class, I’m really suprised (and proud) that most of us have learned to use it somewhat efficiently. In most history grad programs students are taught how to “shred” through books quickly to get at the main arguments, so tackling CSS and working with it hours on end is a whole new world for us. In the long run, CSS will make (in my opinion) working with History and New Media much easier and rewarding. I’m sold on the virtues of CSS; now I’m just trying to become as proficient with it as most of the people who post here…if that’s even remotely possible!

  21. Dann Ryan says:

    You’re telling me, I can’t begin to express the number of hours I spent going through the CSS for my site just for the difference between IE/Mozilla/Netscape on my PC. I haven’t even had the opportunity to touch it on a Mac, and I am definately dreading when that opportunity does arise.
    The most frustrating part is when I get comments from people I know like “Oh, thats your new site? Thats it? I don’t see what the big deal is…” Even other people I know in web design that completely write CSS off and are, for lack of a better word, tablewhores.
    The stuff that CSS can accomplish is amazing, but it doesn’t come without its cost.

  22. anonymous coward says:

    Hmmm…there is a turkey about the position:relative syntax in IE/Mac, maybe in IE across the board, that may have been the culprit.
    You mentioned you tried the obvious and non-obvious. Did you investigate z-index? Use of position:relative allows the use of z-index in IE. The default behavior of z-index may be at fault. If you had not explicitly placed your element in z-index stack, you may be able to see the elements (possibly through a transparent background) but not interact with them. I have recently learned that not knowing what the default behaviors of code might be can lead to hair pulling scenarios of “WHY!?”

  23. Kris says:

    Only two things matter: The KISS Principle and Somebody Else’s Advice

  24. Jerry says:

    Had the same problem with position:relative also. In my case worked O.K. on Mac IE 5.x but on PC IE 5.x, I wasn’t able to resize my table without causing the computer to freeze up. I replaced it with width:100%; and all was well.

  25. tlack says:

    Wow, it must be nice to have clients that can pay you for five or ten hours of layout on a single, simplistic HTML page. Usually when I get to the point of frustration mentioned in this post I just tear out the CSS layout code and make it a table with CSS for cell styling. And you know what? I almost always get it perfect the first time. They suck but they work.

  26. CodeBitch says:

    There are comprehensive lists of known bugs for many browsers, eg Big John’s for IE/Windows and mine for IE5/Mac, at MacEdition. I can’t tell from your description if the bug you encountered is already documented there, but it could be this one.

  27. luis fernandes says:

    What we need is an interactive CSS debugger that allows us to single-step through each application of the css rules and allows us to stop at the exact css rule that is the cause of all that anxiety, grief and hair-loss.
    I don’t know, nor can I imagine the interface of such a debugger or how this would work but once someone writes a prototype css debugger we can all suggest improvements.

  28. Bryan Buchs says:

    27 comments and only one about Journey? Come one, people…
    If anyone hasn’t seen “VH1 Behind The Music – Journey”, well, you haven’t lived. Best. Episode. Ever. Those guys *hate* each other now.
    Anywho, I agree with your point on alloting extra time for x-browser debugging – it’s so easy to under-estimate the time it’s really going to take to get it done. Right.