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.
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.
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 ]").
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
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.
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. ***
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.
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.
Test 35 (and possibly test 0) in Acid3 hit this bug.
I don't believe hyatt is actively working on this, reassigning to unassigned.
Created attachment 18868 [details] Patch to implement last-child and last-of-type
Comment on attachment 18868 [details] Patch to implement last-child and last-of-type r=me! Go team hyatt!
Fixed in r29933.
: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.
Yes, I've done only-child and only-of-type. That's coming in my next check-in.