I just cleared up a funny problem that I’ve had with my site on IE6/Win ever since the redesign. Only folks who were leaving comments via the Discussion Board or my coeditors would have seen this one; it doesn’t affect most users becauase I generally don’t use tables in my content, at least not tables with explicit widths.
The problem was in the feature that allowed users to edit content in the site in an HTML form. The form, which is automatically generated by Manila, is displayed on the page wrapped in a table with width=100% set. Apparently this invokes an obscure bug in IE6/Win in which IE silently adds three pixels of padding when content is displayed next to a float, which if the content next to the float is specified as 100% of the width suddenly means that the content is now 103% wide. To display the content, IE then drops the content down below the float. What this means in practical terms is that every time I wanted to make a change to the site, I had to scroll down past my navigation bar to see the edit area.
The fix turns out to be to specify a dimension (width or height) for the problematic element. In my case, this looks a little like this:
/* fix for tables falling below the float in WinIE; hide from IE5 Mac */
* html #content table { margin-right: -3px;}
/* end hide from IE5/Mac */
So the hack only gets applied to tables in the content pane, and only for WinIE (because it uses the StarHTMLHack wrapped in the commented backslash hack.)
The scariest parts of this are:
- Someone actually did enough debugging to figure out the bad behavior and find a clean solution.
- This makes the second or third browser specific hack I’ve had to introduce into what was otherwise a fairly clean simple stylesheet. Grrr.