a:hover { color: red; } <a href=""> <li> a:hover css not working when placed inside an li... </li> </a> see url

according to my tests, all block elements inside <a> will not inherit style from a:hover ... however, if my memory serve, only inline elements are permitted in <a> is permitted (except <a> of coz) ... as a result, nesting <li>( and <div>, <p> etc.) in <a> is illegal ... and this is a correct behavior ... did quirks mode need this "fix"?

This should work, since: * the spec doesn't say how to handle invalid HTML * We handle it by just creating the document tree as-is, and applying CSS's rules on blocks within inlines * This indicates a bug in our handling of CSS blocks-within-inlines (which can occur for XML documents, or for HTML documents where authors change the 'display' property).

dbaron: Don't we have code to handle "residual style"? e.g. I'm pretty sure <font> <p> ... </p> </font> ...becomes <font></font> <p><font>...</font></p> <font></font> ...or something like that.

Hrm, nevermind, DOM inspector shows that we are indeed putting the <li> node inside the <a> node.

I think "residual style" is only for incorrectly-nested tags, i.e., those that can't be represented as a tree.

oh ok

I think this applies to all styles for a contained in li. See http://grassrootshell.org. All A:link, A:visited, and A:active should have text-decoration: underline; applied to them. A:hover should also have background-color: silver; applied. The same A's which are not getting the hover applied aren't getting the text decoration applied either. GEW

So... is this really an ESM bug or a problem in the parenting of the way the style context of the <li> is parented? Text in the <a> but outside the <li> turns red fine, as does the whole thing if "display:block" is added to the :hover style (and _only_ the :hover style) for the <a>.

bzbarsky: looks like you attached the wrong file for the failing testcase

Yes, I did... sorry.

OK. There are three problems here: 1) The code in nsCSSFrameConstructor::ContentStatesChanged does not walk special siblings. 2) When style is reresolved on the anonymous block created in {ib} situations, the new style context is misparented 3) The optimization in nsStyleContext::CalcStyleDifference leads to the change hint for the anonymous block always being NS_STYLE_HINT_NONE This patch fixes #1 and #2 (the nsFrameManager.cpp and nsFrame.cpp changes respectively). #3 is "fixed" by simply removing the optimization, which is unacceptable (it'll lead to extraneous entries in the changelist and other crap like that). There are a few options here: A) Pass something to nsStyleContext::CalcStyleDifference to tell it to not perform that optimization in some cases. B) Make sure that painting/reflowing the special inlines also paints/reflows the special block. C) Other hacks D) Make {ib} not magle the frame and style context trees. ;) I lean toward (D) myself, but it's a lot of work....

*** Bug 148922 has been marked as a duplicate of this bug. ***

Can we have the "not-perf-hurting part" of the patch checked in for the time being?

Yes, once I have time to clean it up a bit....

*** Bug 158841 has been marked as a duplicate of this bug. ***

This still does not fix this bug, but fixes some of the testcases in the dup bugs. reviews?

to me

*** Bug 165047 has been marked as a duplicate of this bug. ***

Comment on attachment 96823 [details] [diff] [review] Cleaned-up (partial) patch Can't you check the NS_FRAME_IS_SPECIAL bit before calling GetFrameProperty? >+ GetFrameProperty(frame2, nsLayoutAtoms::IBSplitSpecialSibling, 0, (void**)&frame2); Other than that, sr=dbaron.

Comment on attachment 98811 [details] [diff] [review] good catch. Add such a check. sr=dbaron

Comment on attachment 98811 [details] [diff] [review] good catch. Add such a check. r=kin@netscape.com

Comment on attachment 98811 [details] [diff] [review] good catch. Add such a check. checked that in. Leaving bug open for remaining problem for now..

OK... I have the full fix to this, I think. At least it works in my local build. Pity I have no net connection from that machine for now... ;) The change that needs to happen, I think, is that DoApplyRenderingChangeToTree in nsCSSFrameConstructor needs to walk special siblings too, not just next-in-flows. With that change, things are happy here.

Oh, just as a note, I've been running with that patch for a while and haven't had any problems... And yes, this bug is fixed with it.

Comment on attachment 101299 [details] [diff] [review] Patch to fix the remaining problems Oh, this is nice and simple. r/sr=dbaron.

Comment on attachment 101299 [details] [diff] [review] Patch to fix the remaining problems sr=roc+moz Your comment about the outline width inflation isn't quite right. Here we know we're invalidating the whole rect so the details of the comment in nsFrame::Invalidate don't apply. However this inflation should be done when the frame rects are accumulated in UpdateViewsForTree, not in DoApplyRenderingChangeToTree.

This is just a syncing of the patch with tip and making the comment change roc requested

fixed.

checked on winXP with trunk build 2003-01-27-09-trunk. verified fixed

This test case demonstrates that this bug still persists in the current CVS Mozilla

Actually, that testcase works correctly. The background of the <a> is _NOT_ behind the <h2> or the <li>, though. In fact, the actual area covered by the <a> is empty, so you see nothing. Put some text in the <a> to see what's happening.... "color" inherits, "background" does not -- this is why the testcases in this bug used "color"....