IE8 Hover Confusion with nested ul in list item

[Rayzur]

@jameshopkins

Just tried to reply to your email, but got another 554; perhaps you could provide me with another address.

Hi James,
Those are false errors, I got your emails. I think we just about got this wrapped up anyhow.

@jameshopkins

I’ve just taken a quick look at your latest post. You specifically mention that the use of the UL element is a condition to trigger this bug - the UL element itself in fact, wouldn’t be. When addressing CSS bugs like these, instead of mentioning certain elements themselves, we need to determine why that particular element is a trigger (i.e specifying the formatting context, etc), as all CSS bugs are element-independant.

I’ll post back when I’ve done some more investigation and analysed your latest test case further.

James

You are referring to my test from post#16. I didn’t say the UL was the cause, I just said that I set your test case up in a UL. The cause was the pseudo li:hover rather than a:hover.

@Rayzur

Here is your test case as a simple UL with inline list items but with the :hover on the li rather than the a

I have added that condition to my test case

Thanks again for your interest in this and I will check back here to see what your final thoughts are on this buggy behavior.

[jameshopkins]

@Stomme_poes

Has anyone found a *+html for IE8 yet?

You mean a hack? I don’t believe there are any selective hacks but I have already documented a negation hack. An IE8-only CSS rule, whether you use a hack or conditional comment, won’t do anything to fix this issue. Now that we’ve ascertained what the underlying issue is, I wouldn’t recommend using the initial fix of using negative margins.

@Stomme_poes

Because now that the release candidate is out…

We are now well into the RTW (release-to-web) stage; release candidate was the version preceding this one.

@Stomme_poes

Further testing shows even more conditions

Your test case has certainly been a help in identifying some conditions, which has allowed me to further my own investigation.

@Stomme_poes

You are referring to my test from post#16. I didn’t say the UL was the cause, I just said that I set your test case up in a UL. The cause was the pseudo li:hover rather than a:hover.

Probably my mistake in not reading your post properly. The point I was trying to get through when I mentioned this was that as far as CSS test cases go, naming specific HTML elements is unnecessary and can lead to confusion. What we do need to identifying however, is why using particular elements leads to unexpected behaviour; this comes from exploring such things as it’s formatting context, etc, etc. So instead of saying something (assuming DIVs take the form of block-level) like “When a DIV element is placed in the normal flow…”, we should really say “When a block-level element is placed in the normal flow…”. Just a pointer

Results and Diagnosis
To clarify, we’ve discovered two bugs from this thread:-

1. IE8 isn’t ignoring the whitespace text node inserted after the last child element in the DOM [TESTCASE #1 [URL=“http://www.css-lab.com/misc-test/ie8-last-child-node.html”]#2 | [URL=“https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=472846”]BUG TICKET]
2. When the above issue is invoked, and when hovering over the whitespace node itself, styles applied to the :hover state of sibling elements match the first child sibling element in that series [[B]TESTCASE[/B] | [URL=“https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=472851”][B]BUG TICKET[/B]] REGRESSION - not present in IE7
   [INDENT]There are a number of different combinations I found that can trigger this bug; [I]Ray H[/I]'s test case combines both #1 and #2 below;[/INDENT]
   [LIST=1]
3. With preceding block-level sibling - This element must have a font-size equal to, or smaller than the first child inline element
4. With a border value applied to parent - Only specifiying a border on one side of the parent’s box is enough to trigger the bug.
5. With an overflow value (other than ‘visible’) applied to parent -
   [/LIST]

The fix
If you come across either one of the bugs, the best fix (as people have already mentioned here) is to ensure that there is no whitespace between the closing tag of the last chid element and the closing tag of the parent element.

I’ll be filing each bug in a seperate ticket, as although they are inextricably linked, one relates to the HTML/DOM, and the second is a CSS issue based on the first issue. Rayzur, I’ll be crediting you with finding and testing both bugs. I’ll be sure to add links to the tickets once I’ve created them

EDIT - I’ve now created bug tickets and linked to them, and updated my test cases - you now need to have the Ahem font installed to be able to view the test cases properly.

[Rayzur]

James, Thanks for your detailed investigation of these bugs. I had no idea that I was caught up in something so complicated at the beginning, I just knew something was terribly wrong. I appreciate the time you invested in this and all the other bug cases and reports. I read the article on your site about how troublesome it was to file a bug report at MS.

For those of you who are not aware James has also written several articles at CSS3.Info

James Hopkins - Author at CSS3 . Info

[Stomme_poes]

We are now well into the RTW (release-to-web) stage; release candidate was the version preceding this one.

er, what I meant : ) I didn’t know what they were calling it, but I did mean the one that’s out now that they’re encouraging people to DL.

Ray, the bug zapper! You go old man! : )

As just a code monkey I’d also like to thank James for slogging through this. There are a few names I see repeatedly on the MS bloggitty-thing reporting bugs, such a small number of people being the net to catch these things.

[PaulOB]

Interesting thread Ray and James - thanks for the thorough investigation :). It seems the IE whitespace bug is still going to be bugging us for some time to come yet.