Bug 4812 - CSS3: buggy :last-child pseudo selector (Acid3 bug)
Summary: CSS3: buggy :last-child pseudo selector (Acid3 bug)
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Dave Hyatt
URL: http://www.css3.info/selectors-test/t...
Keywords: HasReduction
: 8426 9840 (view as bug list)
Depends on:
Blocks: Acid3 5468 11390 15206
  Show dependency treegraph
Reported: 2005-09-02 11:20 PDT by Simon Percivall
Modified: 2008-02-02 11:25 PST (History)
11 users (show)

See Also:

Test-case to show problem (528 bytes, application/xhtml+xml)
2005-09-02 11:22 PDT, Simon Percivall
no flags Details
Patch to implement last-child and last-of-type (161.20 KB, patch)
2008-02-02 02:29 PST, Dave Hyatt
oliver: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Percivall 2005-09-02 11:20:48 PDT
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.
Comment 1 Simon Percivall 2005-09-02 11:22:26 PDT
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.
Comment 2 Mark Rowe (bdash) 2005-09-03 01:58:19 PDT
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 ]").
Comment 3 Gerrit Kaiser 2005-09-22 14:36:24 PDT
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 
Comment 4 Nicholas Shanks 2005-10-12 06:21:06 PDT
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).
Comment 5 mitz 2006-04-16 13:12:54 PDT
*** Bug 8426 has been marked as a duplicate of this bug. ***
Comment 6 mitz 2006-04-16 13:13:36 PDT
Bug 8426 includes a different test case. See also bug 5287.
Comment 7 Jonathan del Strother 2006-05-09 02:06:33 PDT
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>
Comment 8 mitz 2006-12-16 14:26:23 PST
*** Bug 9840 has been marked as a duplicate of this bug. ***
Comment 9 Nicholas Shanks 2007-02-05 14:00:39 PST
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.
Comment 10 Allan Sandfeld Jensen 2007-08-14 07:28:04 PDT
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.
Comment 11 Eric Seidel (no email) 2008-01-01 22:15:19 PST
Test 35 (and possibly test 0) in Acid3 hit this bug.
Comment 12 Eric Seidel (no email) 2008-01-06 16:59:57 PST
I don't believe hyatt is actively working on this, reassigning to unassigned.
Comment 13 Dave Hyatt 2008-02-02 02:29:21 PST
Created attachment 18868 [details]
Patch to implement last-child and last-of-type
Comment 14 Oliver Hunt 2008-02-02 02:40:24 PST
Comment on attachment 18868 [details]
Patch to implement last-child and last-of-type

Go team hyatt!
Comment 15 Dave Hyatt 2008-02-02 02:48:34 PST
Fixed in r29933.

Comment 16 Nicholas Shanks 2008-02-02 06:27:52 PST
: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.
Comment 17 Dave Hyatt 2008-02-02 11:25:41 PST
Yes, I've done only-child and only-of-type.   That's coming in my next check-in.