Boxing IE6
April 24, 2001
After so many years of being all but ignored by the rest of the Web developing population, the CSS-savvy campaigners for Web standards are finally making enough noise to be heard by that unfeeling majority. It’s a pity their message has to be so complex.
One of the big problems with browser bugs is that they are so fiddly to
identify. If browsers just didn’t implement certain things across
the board – say, “SuperBrowser 7.2 supports CSS1 but not CSS2 selectors”
– it would be easy. But the support gaps are more complex and
granular than that. With current browsers, it’s more like,
“SuperBrowser 7.2 supports background colors except when they are on
CITE tags within a DIV tag that’s styled
with a border, unless the DIV doesn’t contain any
block-level tags, in which case the CITE tag will pretend to
be a block-level tag and be styled correctly but break all subsequent CSS styling until you get to the end
of the DIV.” Ok, I made that up, but it’s not far
off from what Netscape 4.x does to ACRONYM tags. I now
understand why the W3C is trying to modularize CSS and XHTML
– “We support this bit and this bit, but not this bit”
– it’s much easier.
Workarounds exist for some of these bugs. Problem is, unless you know about the sites that document them, you’re not going to know about these workarounds. And worse, the workarounds they come up with are so obtuse that few Web developers are going to stumble across them on their own.
Here’s an example of the sheer arcaneness of the browser bugs that
Web developers encounter every day. The reason Netscape 4.x users see a
different MacEdition to that seen by users of IE, Opera or Netscape 6
is that I couldn’t work around two Netscape bugs simultaneously. The
first is well-known: Netscape 4.x doesn’t draw a background color
across the entire area of a block element like DIV,
P or H1, unless you put a border style on it,
like border:none. Problem is, a DIV with a
border style will crash Netscape 4.0x if that DIV contains
certain other elements, including a table nested within a table (say, any
of our pages with a little yellow callout box), and an array of
HTML 4.0 tags like ACRONYM. So I had a choice between
having a different look and a horizontal scroll bar in all versions of
Netscape 4, and the site not being visible at all to some people.
Crashing people’s browsers doesn’t constitute graceful
degradation, so MacEdition doesn’t look the same in every browser.
Sorry, but don’t blame me; blame Netscape. For those of you
interested in learning about this bug in more detail, I’ve described the
problem in full on another page.
Here’s another one: Netscape 4.x is completely broken when it
comes to styling DT and DD elements, the elements
that go inside a definition list, DL. I first noticed this
when working on another site, and confirmed it with the test
page I originally built to confirm some OmniWeb bugs.
You won’t read about these bugs in the myriad of CSS compatibility guides. They’ve done a great job, but they are just not detailed enough to tell you about these things. They might say that certain CSS style attributes are “buggy” in some browser, but they can’t tell you exactly which elements they break on, or in which minor browser version, or in which combination of other tags. It would be a superhuman effort to construct a full, detailed listing of all these little bugs, and unsurprisingly no one has tried.
What has been tried is a way to get every browser to support the CSS box model in a consistent
way, so that sites can be formatted without tables, kind of like the sample
pages I wrote about last time. Netscape 6, Opera
and IE5 for the Mac support width, border, padding and margin styles the
way the W3C specification says they should be done.
IE5.x for Windows doesn’t. You can work around this by having two
different style declarations with different widths, and then tell
IE5/Windows to use one and everyone else to use the other. Until recently,
the accepted way to do this was to use the fact that IE5/Windows also
doesn’t support the CSS2
child selector > , as in BODY >
#whatever. So you’d apply the IE5/Windows-friendly styles to
#thedivinquestion, and the correct styles to BODY >
#thedivinquestion
The Internet Explorer 6 beta broke this because it supports the box model, which is great, but doesn’t support the child selector. (Actually, IE4.5 for the Mac broke this method too, for the same reason.) It uses the IE5 widths, but renders them differently. That means no consistency across browsers, and unhappy developers.
So the incredibly smart community of people who came up with the original workaround came up with another, which is documented by its originator, Microsoft’s Tantek Çelik and also discussed by Eric Costello at glish.com.
This particular example is from Owen Briggs’ box model tutorial:
#content {
position: absolute;
top: 0px;
left: 0px;
margin: 20px;
background: #666;
border: 5px solid #ccc;
width: 74%; /* ie5win fudge begins */
padding: 10px 10% 10px 15%;
voice-family: "\"}\"";
voice-family:inherit;
width: 55%;
padding: 10px 9% 10px 11%;
}
html>body #content {
width: 55%;
padding: 10px 9% 10px 11%;
} /* ie5win fudge ends */
The idea is that you set the width of your DIV or other box to
the IE5-safe width(width:74%). Then, stick a style in with the
value "\"}\"" (yes, all four quote marks);
in this instance, we’ve used the CSS2 style
voice-family. IE5 for Windows thinks that these quotes and
curly brackets represent the end of that element’s whole style block,
and ignore anything afterwards. Reset that style to something appropriate
– here, voice-family: inherit; – and then set the
correct width and padding so that IE6 can see it (width:55%).
Then you can set the correct width again using the CSS2 selector method
(html>body #content), so that IE5/Mac, Opera and Netscape 6 can
see it.
Now, hands up – who knew about that parsing bug in IE5/Windows? Keep your hands up if you are willing to believe that there isn’t some sub-version of some minor browser with the same bug. Still keep your hands up if you think this workaround that’s required won’t change again when some other browser comes out.
This workaround is brilliant, inspired and works – until the next browser comes along with a completely different set of things it supports and things it doesn’t.
Folks, it’s a beta. Microsoft is the biggest software company in the world and surely has the resources to add the direct-child selector to IE6’s CSS2 support in time for the final release. (Even if the Windows team has to borrow a cup of standards from their Mac-using colleagues in Southern California.)
I support the push to find ways to use CSS more extensively. I just don’t think that exploitation of arcane browser bugs is the way to do it – it’s going to put off designers who are less committed to standards.
Let go. You can’t make things look the same in Opera and AvantGo. So why does it matter that things look a bit different between IE5 and IE6, as long as they look decent? That’s what graceful degradation is all about. I’m not a perfect designer. Maybe I also need to accept that my designs won’t be (pixel-)perfect either. Maybe we all do. It’s a pity, though.