So, I’ve been talking with a few friends lately about this idea of “good habits” with regards to front end web development and I started stewing on a bunch of ideas on how I could write about something like that in an effective way. Sorry to say that this blog post will not be about good habits relating to code but rather as they relate to debugging front end code. I think the latter is valuable and you’ll still get a decent idea of some good habits to work with going forward. Enough rambling, onward!
Isolation, Your First Stop
The bug card you have says some buttons aren’t appearing properly in IE7 and the latest Chrome. So you dive in with your front end tweaker and start disabling styles dynamically hoping you can affect some change in the cascade that will fix the bug live in the browser right there in front of you. Bam! Looks good in Firefox/Chrome and then you open IE and things go to hell. Sound familiar?
It’s at this point that you should really stop what you’re doing and try to isolate the problem. I’ve spent more than enough time hacking in this way to know that it’s a lost cause and infinitely frustrating to boot. The best way to fix a rendering issue in a case like this is to isolate your problem so you can control the number of variables you are testing.
Here’s how I like to break down my isolation debugging process:
1. Create a Test Case
Open a new html file in Textmate or your favorite code editor and create a brand new HTML page. I like to keep a skeleton page so I can do this quickly. This page should have no stylesheets or scripts loaded.
2. Replicate the Environment
Bring the HTML in question into your sample page as it appears in your production code. Also bring only the CSS that applies to those elements and put them in a style block in the head of your sample page.
Once you’ve verified things are behaving the way you want you should probably refactor that HTML and CSS to contain less presentation in your markup. Often markup from legacy applications has been touched by many different people with varying interpretations about how to write HTML; that’s ok but given you spent the time to isolate this problem you may as well do some cleanup.
5. Verify … Again
You’ve made changes, run your test page through the browsers you are testing for again. Repeat step 4 and 5 until you’ve got a good baseline to work with. It’s also good to remember the answer to the question “Do websites need to look exactly the same in every browser?” NO.
Integration is going to result in some more rendering anomalies but now you have a core set of solid CSS/HTML that you know will work. What you do now is go through Firebug/Webkit Inspector and start disabling styles in the cascade that also affect your elements until you get the result you are looking for.
You will probably still have to fiddle but at least you will have eliminated a significant amount of frustration by isolating the problem and proving out your assumptions about how the markup and css will behave in other browsers. Of course you could avoid a significant amount of this cross browser troubleshooting by using something like Compass and SASS, but that’s a topic for another blog post ;)
I hope this was helpful to you and I wish you luck on improving your frontend debugging process and reducing the amount of frustration experienced.