essentials: ie6/win bugs

Three Little Bugs. Imperfections in IE6/Win are impairing the accessibility of the CSS subnav at right and weakening overall design integrity.

We hope this bug report helps Microsoft’s engineers make a good browser even better. When workarounds are found, they will be described at the end of this note. The files below have been frozen for your bug-hunting pleasure, and will not be modified by any workarounds:

bugtest.shtml: Archived version of a page in which the bugs are evident. The page validates against XHTML 1.0 Transitional and CSS and displays as intended in IE5/Mac, Netscape 6.2, Mozilla 1.1, and Opera 5.
basic.css: Archived version of the basic style sheet parsed by all CSS-aware browsers. If your browser cannot natively view style sheets, use this text version instead.
sophisto.css: Archived version of the imported style sheet containing the rules that generate the subnav. If your browser cannot natively view style sheets, use this text version instead.

The Problems

Refer to bugtest.shtml and examine the four “buttons” labeled About, Contact, Essentials, and Pubs, in the CSS subnav below the Search form. In IE6/Win you will see two or three problems:

1. Missing hit points

This is the big one. In all other CSS-compliant browsers, the entire “surface” of each virtual button is clickable. In IE6/Win, only the text itself is clickable. People with visual or mobility problems benefit from having the largest possible live “hit” area, and the CSS has been authored to give them just that. In IE6/Win, the buttons will not work until these users are lucky enough to hit the text. The browser’s failure to recognize that the entire button is clickable may merely annoy non-disabled visitors, but it will significantly impact usability for those with visual or mobile disabilities.

2. Positioning off

In other CSS-compliant browsers, the subnav is correctly positioned directly below the Search box per the design grid. In some copies of IE6/Win, it is horizontally out of alignment, as seen in the screenshot below:

In other copies of IE6/Win, the horizontal alignment is correct, give or take a pixel. It seems to depend on which Windows OS version is being used. The version shown here, captured by Drew McLellan, is correctly positioned within a pixel—as seen in Windows XP with all service packs.

3. Mysterious gaps

In other CSS-compliant browsers, the buttons are separated only by the border, and the entire subnav functions as a single visual unit. In IE6/Win there is a gap of one or two pixels between buttons (visible in the above screenshot and also in the linked screenshot). This gap increases as the page text is user-resized. No gap appears in other browsers, even when page text is user-resized. Of the three bugs, this is the least important because most subtle and least harmful to accessibility.

Workarounds

The bugs listed above have now been “fixed” via workarounds. Refer to the live site and its advanced style sheet, not to the archived versions frozen for purposes of this bug report.

The clickability problem was fixed by assigning a width in pixels to links (changed element marked in bold):

#secondarynav li a {
	display: block;
	width: 96px;
	font-weight: normal;
	padding: 1px;
	border-left: 2px solid #6cc;
	border-right: 2px solid #6cc;
	background-color: #399;
	color: #cff;
	text-decoration: none;
	}

We chose 96px because overall width is 100px and the element includes a 2px border on each side: 2px (left) plus 2px (right) plus 96px equals 100. No other CSS-compliant browser required such a rule. But with the rule added, the display is now roughly the same—and the entire button surface is clickable—in all compliant browsers tested.

Many readers wrote in suggesting a similar approach but prescribing a percentage value, most often 100%. That value fixed the display in IE6/Win but broke it in Mozilla and other compliant browsers because the math violated the box model. (100% left no room for the border elements.) Other readers suggested slightly lesser percentages such as 98%. Again the math would not have been quite right. 96% might have worked, but why guess at percentages when the entire unit is spec’d in pixel values?

The vertical gap problem was loosely corrected by specifying line-height in the list item (changed element marked in bold):

#secondarynav li	{
	text-align: center;
	border-bottom: 1px solid #066;
	width: 100px;
	margin: 0;
	padding: 0 1px 1px 1px;
	font: 10px/12px verdana, arial, sans-serif;
	color: #cff;
	background: #399;
	}

Again, this should not have been necessary—and was not needed in IE5/Mac, Mozilla 1.1, Netscape 6.2, or Opera 5. But it approximately did the trick. (There is still a 1px gap between elements in IE/Win, but we can live with it.) A line-height of 11px was tried first, but that value upset the balance in Mozilla. 12px is 120% of 10px (the assigned button text size) and roughly approximates the default leading in most browsers when no line-height value is specified.

Somehow, in making these changes, we seem to have also fixed the positioning problem that marred display in some versions of IE/Win. At least, we can no longer reproduce that bug. Don’t ask us how the changes above could have influenced a positioning bug. Some bugs are simply inexplicable except as software hiccups caused by unforseen interdependencies.

The changes listed above took approximately 30 minutes to figure out and implement, and were made within an hour of posting the initial bug report.

For more on using CSS to style structured markup, see Mark Newhouse’s “CSS Design: Taming Lists,” at A List Apart. If you can keep up with it, the CSS-Discuss mailing list created by John Allsopp and Eric Meyer in January 2002 is an unsurpassed source of information on CSS tricks and browser workarounds. (Had we been able to keep up with that list, we might well have known about these IE/Win CSS bugs and their workarounds before beginning this design exercise.)

Dave Rutledge and Drew McLellan contributed to this bug report as did many readers whose suggestions and comments we read gratefully, though we were unable to respond due to the volume of submissions received.