Brain on Fire » Blog Tim McCormack says words

I am pleased to announce that the Crutchfield website has made a large step towards standards compliance. With this latest redesign, we’ve reorganized the look and feel, layout, and much of the presentation code. Disclaimer: I am not speaking as a representative of Crutchfield in this or any of my posts.

Tables

One effort I’ve been very involved in is the stripping away of many nested tables, replacing them with more appropriate elements such as unordered lists, paragraphs, properly id’d and class’d divs, and definition lists. Mozilla users can use the web developer toolbar to outline tables — new code is represented by the lack of profuse, colorful lines.

The reason for so many tables is twofold:

Building on legacy code

The website has been around for many years, from before there were effective and semantic means of styling content. To make a solid 1-pixel border, the designers would nest a 1-cell 1-pixel-cellspacing table inside a black-background 1-cell table. Later designers didn’t have time to fix old code that wasn’t obviously broken. Table soon grew so complex that the prospect of delving into their structure was quite frightening.

The use of a CMS.

A common problem I’ve seen in our site is the wrapping of function calls with 1-cell tables to prevent the contents from spilling out of its box. Ideally, there would be one standard way of wrapping content, but we often have the need to pull the same content into different environments. Again, the use of contextual selectors in CSS will go a long way in resolving this issue.

Dropdown menus

The dropdown menus are my proudest work on the site because they also caused me the most grief. They work as designed in Firefox, Safari, and Win/IE, with a delay before they disappear on mouseout. My original code (not in use anymore) was a possibly unique combination of Gilder–Levin Image Replacement (GLIR) and Son of Suckerfish Dropdowns. To recap, this involves using the :hover pseudo-class to show and hide nested unordered lists. A bit of javascript is executed onload in IE to attach mouseover/mouseout functions to the list items. These functions add and remove the class sfhover from the list items. Firefox was allowed to use the :hover pseudo-class natively, bypassing the javascript. Since IE 5 on Mac is too far behind to understand any of this, I used the Mac IE 5 hide method. This prevented the dropdowns from being seen; it degraded gracefully to a button bar.

Then the debugging began. To summarize: list item sizing, IE flicker, decay delay (not a bug, a request), <select> element showing through, cross-domain security notice.

The first problem I experienced with this combination was a <li>-sizing bug. The contents of the dropdown needed to expand and contract depending on how long the text was, so I couldn’t set #prodnav li { height: 35px; } for the top-level items, which needed explicit heights for the image replacement. If IE supported direct-descendent selectors, there would have been no problem. Once that was dealt with using height: auto; or something of the sort, I moved on to the IE-flicker bug. Every time I would mouse up and down a menu in IE 6, the background-image at the top would flicker, revealing the text behind it. I eventually traced this to IE’s inability to cache background images. Mousing over the border between two list items in the menu caused a mouseout/mouseover event pair, so IE would have to reload the background twice. Mousing up and down rapidly could quickly generate over 1000 calls to the server. I had to put this bug off for later.

I was asked to add a decay delay to the dropdowns for accessibility. Mousing off by even 1 pixel made the menu disappear immediately, a concern for low-motor users. This obviously requires javascript, but I hoped to use position a div around the ul, effectively expanding the onhover area. It didn’t work. I spent about a week solely on the decay delay, which is still in use. I won’t write about it in this post, but the basic idea was to create a delayed version of the IE hover fix running in parallel.

Close to the release date, the IE-flicker bug floated to the top of my to-do list. I made the decision to abandon image replacement and use image tags instead. I added javascript to alter the image source URLs on mouseover and mouseout, and the now-removed span.covers from GLIR were no longer preventing Mac IE 5 users from clicking the top-level links. In retrospect, I should have used this technique to begin with, but I was drawn like a moth to flame of image replacement.

The last bug was certainly one of the nastiest. The “GO” button for the search form was floating up above the first menu in IE, due to some relative positioning that was quickly removed, helped along by z-index. I thought a similar fix could be used to prevent <select> elements from showing through in IE — I was dead wrong. Apparantly, this is a known IE bug. I learned about the bug and the <iframe> suppression approach from Joe King’s blog. The essential problem is that certain form elements have an unchangeable z-index of infinity, but iframes can cover them. Employing Joe King’s solution, I set another onload fix for IE that uses DOM methods to insert iframes behind the unordered lists. I though I was done, but the iframes came back to bote me later.

The last bug occurred during the internal last-minute pre-launch testing. Upon entering a secure portion of the site in IE, a notice would pop up stating that there was mixed secure/non-secure content. It was discovered that the dynamically-generated anonymous iframes were prompting the notice. Since the src attribute was not being set (I was using the createElement method), IE was assuming a source of about:blank or something of that nature. My solution was to use the DOM setAttribute method to set the source to “/null.txt”, which piggybacks onto the protocol of the page that calls it (http or https). The dropdowns were finally finished.

Known problems

Mac IE 5 is having some serious issues with the dropdowns – it isn’t showing the menus at all, and some of the area beneath them is unclickable. This has all the signs of an absolutely positioned element, but I don’t know why the menu is invisible. Edit 2006-3-16: I later learned (using the Aardvark Firefox extension, which was perfect for solving this) that the <ul> was expanding over the rest of the page in Mac IE 5.

For the future

There’s only so much I can talk about on my blog. I can’t discuss internal code, our databases, or our software. I can’t reveal our plans for the future or specific tweaks that are in the works. But I can tell you that this redesign represents a commitment to more robust, accessible, meaningful code, and that I am very excited to be part of it. Yay for standards!