• March 22nd, 2008
• Filed in
  • Agile Development
  • CSS
  • Web Design
  • Web Development
  • Work

I recently spent the day debugging Internet Explorer. I save it for the absolute last step in front end development before pushing a site live. I want to avoid Explorer as much as possible.

I figured my process would be worth sharing. This is my setup.

1. MacBook running Firefox with the Web Developer Plugin and Firebug plugins installed.
2. Old Toshiba Laptop 1.8ghz barebones Windows XP installation with IE6
3. Parallels installed on the MacBook with IE7 on Windows XP SP2

With this setup I can test for any modern browser with any kind of significant market share.

• Firefox Mac
• Firefox Win
• IE 6 + 7 (soon to be 8 as well)
• Camino
• Safari

Debugging IE issues is probably the most painful thing about my job, but one that’s made a little bit easier because of my approach so I thought it’d be useful to share.

I develop 9-5 in Firefox so any rendering bugs usually come to my attention right away and I’ll fix them immediately. Camino is based on the same Gecko rendering engine so I don’t have to worry about anomalies there. Safari does a good job rendering everything and my colleagues use it as their day to day browser so we usually catch any rendering bugs that way.

Then it comes down to IE debugging. I only concern myself with IE6 and above, I can handle well for modern browsers, besides the market share of browsers that fall outside this range is really insignificant statistically. For small development teams it’s hardly worth the extra effort to pay attention to the long tail of browsers.

Looking at Google Analytics for a heavy traffic site that I work on:

5.6m Visitors from 8/1/07 - 3/20/08

IE is still dominant - so testing for these browsers is essential.

If we look at the last 6 months, IE7.0 and IE6.0 are neck and neck ~50/50, however:

In the first 3+ months of 2008 you can see that IE7 has taken a significant leap above IE6 in the market 61/39 and IE 5.5 has gone to a 0.12% market share to a meager 0.07% market share.

That leaves us only concerned with IE6 and IE7 (and hopefully upcoming IE8 will be a non factor). The best way to deal with CSS and IE is by leveraging something called conditional comments

Before conditional comments I relied on browser hacks to differentiate between browsers, but conditional comments are a lot easier and so much more effective. Currently I use these declarations:

<!--[if IE 6]>
<link rel="stylesheet" href="/stylesheets/ie6.css" type="text/css" />
<![endif]-->
<!--[if IE 7]>
<link rel="stylesheet" href="/stylesheets/ie7.css" type="text/css" />
<![endif]-->

I start with IE6 and clean up any rendering issues - then I move on to IE7, which invariably has fewer issues to deal with. Because IE does not have a handy dandy tool like Firebug to help me diagnose the problem this process usually involves a lot of trial and error. It’s a very iterative process and one that my Agile Development Workflow is well suited for.

One technique I’ve found to be indispensable is assigning various background colors to the markup that I’m trying to debug. Often this is all I need to target CSS rules run amok. Over time you can avoid generating certain CSS + HTML that will break IE altogether - and that’s what separates the experts from novices.

Was this helpful? How do you approach debugging CSS in IE? Share!

Popularity: 10% [?]

• March 14th, 2008
• Filed in
  • Web Development
  • Work
  • jQuery

I jQuery. There I said it loud and clear across the Internet so everyone knows it. I don’t ever want to use another framework.

When I work with large sites with many jQuery rules that have to be applied, sometimes this can cause sluggishness - especially if you’re using jQuery for progressive enhancement.

I was recently hit with a performance snag with jQuery - I just had too much going on in my jrules.js file - this is what I use to apply all of my DOM methods with jQuery. jQuery performance is great - and with the packed version it’s footprint is miniscule but when you parse a massive DOM and apply a ton of rules sluggishness ensues especially when using progressive enhancement to hide/show multiple objects.

Right now I have a jrules.js file that is big, mean and has over 200+ lines of jQuery goodness to apply every time a page loads.

I hit performance issues when I have pages with hundreds of tags in the markup and a ton of content - you can see where I’m going with this.

What I came up with and use for most of my recent projects is a way to pass over those jQuery rules that don’t need to be applied or even looked at on certain pages. This is how I go about it:

First I break up my rules according to what page they’re on.

document.ready(function() {

// GLOBAL

// HOME

// LOGIN

});

If you can segregate rules and only apply them when they’re needed you’ll significantly improve the speed with which jQuery can handle it all, especially when you’re dealing with massive DOM trees.

I leverage top level CSS inheritance to bring it together. On my pages assign an ID to the body tag from which all my jQuery rules will be executed upon.

<body id="home">

You can use .length or .size() - they’re synonymous to test if the jQuery object is avaiable in the DOM, if it doesn’t exist jQuery doesn’t have to bother with it.

Rules only used on certain pages can now be filtered and jQuery can pass over huge blocks of declarations of whom we know don’t exist in the current DOM anyhow.

document.ready(function() {

// GLOBAL
// DOM elements that exist on every page

$("input[@type=password], input[@type=text]").addClass("text");

$("input[@type=password], input[@type=text], textarea").focus(function() {
    $(this).addClass("focus");
});

// HOME body#home

if ($("body#home").size()) {
    // only applies rules on the homepage
    $("p").hover(function() {
        $(this).addClass("change")
    }, function() {
        $(this).removeClass("change")
    );
}

// LOGIN

if ($("body#login").size()) {
    // only applies rules on the login page
}

});

For simple pages with a few rules and a small DOM this is definitely overkill, but if you’ve noticed even a nano second of lag when jQuery applies your rules and see the DOM rearrange itself at page load try this out and let me know how it worked for you.

Last night when I attended a meeting of The Markup & Style Society at the Filament Group office. I got a chance to speak with Mr. jQuery himself - John Resig about my performance issue and I shared my solution to the problem. I was unsure I approached it the best way and there wasn’t a better solution available out there, but he assured me the way I was going about it was sound so consider this method Resig Approved™.

UPDATE

John alerted me to this: Seems that jQuery is now more popular than Prototype - far as search queries go at least. Congrats John & the jQuery team!

Popularity: 10% [?]