How do you tell the difference between a web application developer, and the Average Joe who’s not actually a web app developer but did stay at a Holiday Inn Express last night?

Well, if you ask them how they feel about Internet Explorer and they respond with an expletive-filled tirade of hate and disgust, good chance they are actually a web application developer. Sure this is probably an over-exaggeration, but the Average Joe out there would probably never think of the need for testing an application in all of the major browsers (for Rally, this is IE, Firefox, Safari, and Chrome). They’d probably think something like, “If it works in Firefox, why wouldn’t it work in all browsers?”, or “All of the web applications that I use look nearly identical in all browsers so all browsers must work the same”. They couldn’t be more wrong.

The engineers at Rally have spent many hours ensuring that our users can use our application in whatever browser they choose, assuming they choose one of our supported browsers. (The same can probably be said about the engineers at nearly all of the other popular web applications in use today.) The majority of our time spent making our app cross-browser compatible is spent on making it work in Internet Explorer. It’s for good reason too: approximately 50% of our users access the Rally application with Internet Explorer, compared to 41% for Firefox. Of the users that use our app with Internet Explorer, 60% of them use Internet Explorer version 6.

I’d like to discuss a few of the interesting IE6-specific problems we’ve solved recently:

1. ExtJS’s Ext.layout.BorderLayout doesn’t render the splitter element in Internet Explorer 6

We created the Widget Catalog window on our new Dashboard Beta page by extending Ext.Window in the following manner:

RALLY.ui.dashboard.WidgetCatalogWindow = Ext.extend(Ext.Window, {
 title : "Widget Catalog",
 width : '70%',
 height : 400,
 layout : 'border',
 ...
});

As we were putting the CSS styles on this window, we noticed that the dark-blue vertical splitter element that separated the two panels of the window didn’t appear to be rendering in IE6. However, it was present and colored properly in every other browser, as shown below:

WidgetCatalog

We tried to put a border on the splitter element and the border still did not appear in IE6. However, when you moused over where the splitter should be, the mouse pointer changed to a drag-type pointer, and you could still drag and drop the splitter as you would expect so it seemed like the element was there, but IE6 wasn’t coloring it for some reason.

After poking around for awhile, we stumbled upon a web page that lead us to believe we should mess around with the CSS “filter” property. This did the trick:

.ext-strict .ext-ie6 .widget-catalog-window .x-layout-split, .widget-catalog-window .x-layout-split {
 background: #0d345f none !important;
 filter: none;
}

2. The multiple class bug in Internet Explorer 6

If you have access to more than one Workspace in our application, there is a “Workspace Picker” available to you in the upper-left hand corner of the application:

WorkspacePicker

Notice the border surrounding the words “Workspace 1″. This border should show up if BOTH of the following conditions are met: the user has access to more than one workspace AND the user’s mouse is positioned over the workspace picker element. If both these conditions are not met, the border should not appear on mouse over.

We thought that the following CSS would adequately meet our needs:

#main #header div.simple-picker.selectable.sp-over {
 border: 1px solid #3f84a4;
}

“sp-over” is the class that gets added to the workspace picker on mouse over, and “selectable” is the class added when the users has access to more than one workspace. Our problem was that, in Internet Explorer 6 only, the border was rendered whenever the user’s mouse was over the workspace picker, regardless of whether they actually had access to more than one workspace. This was caused by what Paul Irish deems “The Multiple Class Bug” in his blog post here.

Essentially IE6’s CSS parser was interpreting the “div.simple-picker.selectable.sp-over” selector as simply “div.sp-over”. Therefore, on mouse over, the “sp-over” style was being applied to the workspace picker element regardless of whether it had the “selectable” class and hence a border was shown.

Once we had figured out the problem, a workaround was not difficult to implement. We decided to create a new CSS class just for IE6 that would be applied to the workspace picker element when BOTH conditions for the border to be shown were met. We added this in the onRender(…) method of the WorkspacePicker, which extends Ext.Component:

RALLY.ui.picker.WorkspacePicker = Ext.extend(Ext.Component, {
 onRender : function(ct, pos) {
   if (this.el && this._isSelectable()) {
   this.el.addClass('selectable');
     if(Ext.isIE6){
       this.el.addClassOnOver("sp-over-selectable-combined-class-for-ie6");
     }
   }
 }
 ...
});

Additionally, we needed to modify the CSS to use this new class:

#main.ext-ie6 #header div.sp-over-selectable-combined-class-for-ie6,
#main #header div.simple-picker.selectable.sp-over {
 border: 1px solid #3f84a4;
}

However, this wasn’t quite good enough for IE6. A border will still be applied to the workspace picker when it is not selectable because the second selector (#main #header div.selectable.sp-over) will still match when the mouse is over the workspace picker (remember, IE6 reads “div.simple-picker.selectable.sp-over” as simply “div.sp-over”). So, we added the following CSS to make the border color the same color as the background (so that, to the user, it would appear as if there was no border) if the sp-over-selectable-combined-class-for-ie6 was not present on the workspace picker element:

#main.ext-ie6 #header div.simple-picker {
 border: 1px solid #085478;
}

Interestingly, this newly-added selector is more specific than the “#main #header div.simple-picker.selectable.sp-over” selector in IE6’s eyes, but only because of the browser’s crappy CSS support. If you calculate the specificity of the original selector according to standard rules, you would come up with a specificity of 2, 3, 1 (number of ID, class, and element selectors). However, remember that IE6 sees “div.simple-picker.selectable.sp-over” as simply “div.sp-over”, so in IE6’s eyes the specificity of this selector is actually 2, 1, 1. The specificity of our newly added selector (#main.ext-ie6 #header div.simple-picker) is 2, 2, 1. Therefore, our newly-added selector will be applied by IE6.

Finally, please note that all of the CSS selectors added to fix this problem use the handy ext-ie6 class, which is conveniently added by Ext only in the case when the application is accessed using IE6. Additionally the added JavaScript code is wrapped by the Ext.isIE6 check that only returns true when the application is accessed using IE6. Both of these mechanisms made this problem much easier to solve.

These are just a few of the many interesting IE6-specific problems we’ve solved recently. Solving browser-specific problems is a big part of web application development but I feel like I’ve I only started to scrape the surface in this area, because, truth be told, five months ago I was just an Average Joe who stayed at a Holiday Inn Express ;) . Ah, how much I’ve learned.

Comments: No Comments >> Add a Comment

Tags: