Bug 4812 – CSS3: buggy :last-child pseudo selector (Acid3 bug)

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Simon Percivall]

Styling a <li> with li:last-child:after will style each <li>, instead of only the last. This happens with 
embedded styles and with a linked style the first time the page loads.

[Simon Percivall]

Created attachment 3723 [details]
Test-case to show problem

The file shows embedded styles. It works (like I believe it should, anyway) in
Gecko. If you link the CSS, it'll work after a reload.

[Mark Rowe (bdash)]

Confirmed with WebKit 412.7 and ToT.  The behaviour seems quite arbitrary -- on some page loads it 
appears as "[ test1 ] test2 > test3 ]" which means it is correct for one of the <li> tags.  Other times it gets 
rendered as "[ test1 ] test2 ] test3 ]".  With ToT refreshing the page results in correct results until the 
cache is emptied.  With WebKit 412.7 refreshing occasionally results in the correct rendering, but more 
often seems to result in one of the three incorrect renderings (the third being "[ test1 > test2 ] test3 ]").

[Gerrit Kaiser]

Discovered this bug as well (WebKit 412.5). In embedded WebKit-Views it a CSS rule is applied to all child 
element (not only the last) and stays that way, Safari shows this only right after page load in my test. See 
http://planetgk.de/tests/safari/lastchild.html

[Nicholas Shanks]

This has been present for a long time and is discussed in other places such as bug #3442 (which was 
originally supposed to fix it, but the fix got rejected and that bug is more limited in scope now).

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

Bug 8426 includes a different test case. See also bug 5287.

[Jonathan del Strother]

I'm not sure if this adds anything useful, but thought I'd point out that dynamically created parents don't suffer from this problem.  (eg create a new ul with javascript, and it's fine.  Simply adding an li child to an existing ul leaves you with the same problem, though.)

<a href="http://www.steelskies.com/download/lastChild.htm">for example</a>

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

[Nicholas Shanks]

why not remember the previous child element being worked on whilst processing the document, and when the parent closes, go back and re-style that child. That way the li:last-child matching element would only get processed when you encountered <ul> rather than in a second styling pass or something.

if this can't be fixed in time for Leopard, recommend removing support for last-child (and related selectors) altogether. Better to not support at all than have completely incorrect implementation.

[Allan Sandfeld Jensen]

Correctly implementing :last-child is directly related to correctly implementing :empty. Both has to trigger a restyle when a close tag is parsed. :last-child needs a restyle of the last child-element, and :empty requires a restyle of the closing element.

Also both could be solved by always waiting to create the style until the next tag and potential element have been parsed.

And both are sensitive to Element.appendNode where they may need to trigger a restyle of the previous sibling or the parent node.

[Eric Seidel (no email)]

Test 35 (and possibly test 0) in Acid3 hit this bug.

[Eric Seidel (no email)]

I don't believe hyatt is actively working on this, reassigning to unassigned.

[Dave Hyatt]

Created attachment 18868 [details]
Patch to implement last-child and last-of-type

[Oliver Hunt]

Comment on attachment 18868 [details]
Patch to implement last-child and last-of-type

r=me!
Go team hyatt!

[Dave Hyatt]

Fixed in r29933.

[Nicholas Shanks]

:only-child and :only-of-type are easy now, since they just need to check that :first-… and :last… are both true. I would have suggested doing that in this patch if you hadn't already checked it in.

[Dave Hyatt]

Yes, I've done only-child and only-of-type.   That's coming in my next check-in.