Journal
IE6 Multi-Class Bug
8 August 2005 › 13 comments
When developing a site for a ministry recently, I noticed a rendering problem with Internet Explorer 6 on Windows (big surprise). After talking it over with Chris from ParticleTree, we both concluded that (to our knowledge) this had not yet been documented. So, the purpose of this article will be to explain what I am calling the IE6 Multi-Class Bug, for lack of a better term. In essence, it is the failure of Internet Explorer to render backgrounds for elements that have both an ID and a Class defined.
Normally, this is not a problem, but for the site I was working on, I had defined a <div> with the ID photos and gave separate class names based on which section of the site you were on. So, I had the typical names about, contact, welcome to correspond with the various section names. I looked at it in Safari and Firefox and there were no problems. Then, I fired up IE6 to have a look, and noticed that the welcome page did not work.
I clicked around through the site, and noticed that none of the photo <div> backgrounds loaded, except for the one on the about page. Puzzled, I went to my CSS to try to find the source of the problem. Since I’ve recently started alphabetizing all of my CSS files, #photos.about appeared first, before all the other site-section names. After showing this to several web designer friends, we were all stumped as to the cause of the error.
Finally, I realized that this was some sort of parsing/rendering error in IE6. It was going through the list of #ID.class for the photos <div>, but only applying a background to the first one, about. For all the rest of the classes that were applied to the same ID, IE6 simply skipped over them, failing to render the distinct backgrounds for each page.
The fix was simple, as all I had to do was remove #photos from each class, and simply have the class names defined in the CSS. While this is not a revolutionary finding, it is certainly one that could potentially cause headaches for web designers. So, I thought I would give everyone a heads-up, so that you are aware of this potential snag. I have also made mention of it on the IE7 Blog, so hopefully it will be fixed in the future release.
For an example of what this bug looks like in action, check out this page I have set up as a demonstration: IE6 Multi-Class Bug.
Discussion + Dissension
Comments closed after 2 weeks.



#1 Emma Dobrescu
But if you use ”#photos .about” in the css to define the class, it will work. And you can define a second class, like ”#photos2 .about” that won’t override the first, as it’s a selector.
#2 Ingo Chao
Nice bug documentation.
I wouldn’t name it “multi-class” bug, because another bug with multiple classes in IE is already well documented, i.e. [1].
You have a combination of #id.class in one rule. Occasionally, this is discussed on css-d, i.e.
css-d1
css-d2
Good to have a link to a thorough description!
[1] quirksmode bug report
#3 Nathan Smith
@Emma, that’s true, but a far more simple solution is to just drop the #photos ID name altogether, and only define the class names, which is what I ended up doing. Having separate ID’s just to handle the IE6 bug is a bit redundant, and defeats the purpose of using the classes to handle the backgrounds in the first place.
#4 Nathan Smith
@Ingo: You’re right, it would appear that the problem I was having is related to the css-d1 listing that you provided. Still, I thought it best to do a brief write-up, and provide a demonstration of the bug in action, so that people would know what was going on.
#5 Ingo Chao
Of course. As I said, a nice demo!
#6 Yannick L.
Thanks Nathan. Very Interesting discovery. Will look out for this when working on future website.
#7 Nathan Smith
@Yannick: I don’t think I “discovered” it, as it was made clear to me on the IEBlog that people are already aware of it. However, I am the only one, to my knowledge, who illustrated the bug using pretty pictures of flowers. :)
#8 Christian Fecteau
Can’t you just use this:
.p {
height: 150px;
width: 150px;
}
.a {
background: url(1.jpg) no-repeat;
}
.b {
background: url(2.jpg) no-repeat;
}
.c {
background: url(3.jpg) no-repeat;
}
.d {
background: url(4.jpg) no-repeat;
}
.e {
background: url(5.jpg) no-repeat;
}
div class=”a p”
div class=”b p”
div class=”c p”
div class=”d p”
div class=”e p”
#9 Nathan Smith
Christian: You could, yes. I think that would work. Though, I wouldn’t recomment having a class named
.pbecause it looks to much like a reference to an HTML P paragraph. As I’m skimming my CSS, that would throw me off I think. But, whatever works for you is just fine.As far as I can tell it’s all semantically correct. I didn't report this bug because it's a crucial issue., There definitely are easy work-arounds, such as the one you mentioned. I just reported it so that it would be documented and so the IE7 team can fix it before their next release. Hopefull it will get patched up.
#10 Ryan Heneise
I had a similar problem where IE was just skipping my classes. It went like this:
#Flash{
border, padding, etc…
}
.good{
border-color: #9c9 !important;
background: #E2F9E3 url(../images/icons/flash_good.gif) !important;
color: #060 !important;
}
.bad{
like good, except red…
}
Your fix (removing #Flash) worked, but IE was still not rendering the .good and .bad classes properly. It appears that it was simply overriding the attributes in the classes with the attributes in the ID. The only workaround I found was to tack on ”!important” on each line of the class declaration. Ugly, but it seems to work.
#11 Nathan Smith
Ryan: Yeah, I think that therein lies the essence of the bug. Once something has been set, IE says “Ah, that’s been set, don’t ever have to re-visit it again!” That of course, isn’t a problem for other browsers, but IE assumes that we never want to override our own styles, and we get stuck with whatever was defined first in the CSS.
#12 Dom
i’m having a similar problem with classes being ignored by ie. Can you please elaborate more on the fix. Give the code you would use to fix the example link on the page.
Sorry I’m slowly learning this stuff.
#13 Nathan Smith
Dom: To fix the problem, you would just need to remove the ID and simply leave the Class name. For instance, in the tutorial’s CSS, you would need to change
#photo.back_1to.back_1, dropping the name of the ID#photo.