Home of Doug Gibson, full life cycle ColdFusion web/application developer

Eric Meyer's CSS Reset v1.0 Doesn't Play Well With IE

posted Mar 8, 2008 at 02:24:34 PM by Doug Gibson.

Building this new blog/site with all of the best practices in mind that I can think of has been an adventure. I had planned to blog more in-depth on some CSS-specific things (and will), but this issue popped up and I thought I'd share it.

When I saw that CSS-god Eric Meyer had updated his CSS Reset file to version 1.0 and given it a permanent home, I immediately checked it out and integrated the changes into my reset.css file. Granted, it's still mostly Meyer's file, but with some small tweaks.

By way of some background - a reset.css is a special CSS file created solely for the purpose of eliminating browser default issues and cross-browser compatibility problems by explicitly setting the styles of elements to be the same in all browsers.

It wasn't until I had posted the changes live - yes I did test locally first - that I noticed something was amiss with the CSS in Internet Explorer. Upon further testing, both IE 6 and 7 were affected. The main area that seems to be affected are my tables in the admin area, which no one can see of course. In particular the table row striping and highlighting of inactive/draft records was gone. Yet everything looked just fine in Firefox.

The way I stripe my table rows is fairly common inline ColdFusion inside of a query loop - not ideal in some ways, but effective.

<tr <CFIF currentrow MOD 2>class="greybar"</CFIF>>

I changed all sorts of stuff in my main CSS, added greater specificity to the rule in question, added !important, all to no avail. I gutted my table of recently added col and colgroup tags. Nothing.

I removed the reset.css from the header and *poof* it worked again. Finally I noticed a new line of code in the global reset:


html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin:0;
padding:0;
border:0;
outline:0;
font-size:100%;
vertical-align:baseline;
background:transparent;
}

The last line with the shorthand background attribute is new from his previous version. I took it out and everything worked again.

But why stop there? I'd been having trouble with the background shorthand property in other places, so decided to change it to background-color:transparent. Broken in IE again. I changed it to a solid color to see if the transparent value was the problem (I know it was a problem waaaay back a long time ago, but I don't even remember which browser any more - NS4 maybe?). The entire table turned red, as expected.

Finally, I changed the background back to transparent and immediately after that rule inserted this one:

tr{background:#F00}

Still no effect in IE. So to the best of my estimation, IE either has problems with applying background colors to TRs, which seem unlikely because they've always worked otherwise, or with applying transparency to TDs, or perhaps just showing TRs through TDs. In any case, I cannot leave the background property in that style declaration, so it's gone, and I would recommend you do the same unless there's a REALLY good reason it's in there.

Of course, I'm not ruling out that I could have screwed something up myself, but it seems to be a browser bug with IE if !important and specificity had no effect at all.

Update: For further discussion and potential solutions to this issue, see my follow-up blog, Overcoming "background: transparent" In Internet Explorer.


6 Reader Comments

1. John Bliss writes:

Confirmed. Using my wedding website (and Spry sandbox - http://labs.adobe.com/technologies/spry/) I pasted the reset at the top of my existing main CSS file and I witnessed the same phenomenon as you. I deleted the background: transparent; line and now everything looks right...except...the left nav (a Spry Menu Bar) magically valigns bottom. This despite the fact that it's in a TD with valign="top". (I did not post this to production, but it should be easy to imagine what I'm describing.)

I do not have time to run this to ground right now but thought I'd post to see if ya'll have any ideas as to what might have caused this.

# Mar 9, 2008 @ 11:42 AM ET | IP Logged
2. Eric Meyer writes:

Goldarnit, I forgot about that little IE bug. What's happening is that in order to make it look like the 'tr' has a background, IE copies that value to the 'td' elements in the row. It's a visual sleight-of-hand to cover the fact that IE can't actually style 'tr' background. The reset changes the 'td's back to transparent.

So now I have to decide: take it out or leave it in? If I leave it in, do I document that quirk in a comment or not? Le sigh.

But thanks for writing this up. I should go write it up myself and see what kind of reactions I get.

# Mar 10, 2008 @ 2:27 PM ET | IP Logged
3. dgibson writes:

Thanks for the comment, Eric. That's an interesting bug I haven't experienced until now. Your explanation gives me a way to work around it (with descendant selectors) even if I keep the background:transparent too.

But my question then is what is the purpose of the declaration? Are there any known browser issues (minus NS4, which everyone filters out) with background inheritance that necessitate setting the background explicitly like this? If so, I would definitely keep it in there and put the IE fixes in my iehacks.css. If not, it seems kind of silly to declare it and have to undo it for IE (and on multiple classes and hover states) for no other good reason.

# Mar 10, 2008 @ 4:49 PM ET | IP Logged
4. dgibson writes:

Hey John. Sorry - seems my spam filter caught your comment and I'm not trained to check my blog so often yet like I should... I can't say I have any idea why your table cell would be aligning bottom though. Is there any other content in there that it is floating or positioned around?

# Mar 13, 2008 @ 11:44 PM ET | IP Logged
5. John Bliss writes:

&gt; Is there any other content in there that it is floating or positioned around

Nope. You can view source on http://www.brandiandjohn.com/home.cfm and look at the:

TD WIDTH="139" VALIGN="top" BGCOLOR="#DBE8D3"

...with only the Spry menu in it:

ul id="MenuBar1" class="MenuBarVertical"

...valigns top without the CSS Reset (as on production) and valigns bottom with the CSS Reset (in both IE8 and FF2).

# Mar 14, 2008 @ 6:10 AM ET | IP Logged
6. dgibson writes:

Very odd. Nothing jumps out at me, but when I use the Firefox developer toolbar and highlight block level elements or current elements (which shows you the DOM tree and ids/classes on the current element), I can see the containing UL for the menu has some weird dimensions stretching out to the left side of the page. That would be my main concern. Try commenting out the other table-specific styles in the CSS such as <code>caption,th,td{text-align:left;font-weight:normal}</code>.

# Mar 16, 2008 @ 10:21 PM ET | IP Logged

To minimize comment spam/abuse, comments are closed on articles over a month old.