Bug 17680 - Combination of checked pseudo-class and multiple chained sibling selectors fails in Webkit
Summary: Combination of checked pseudo-class and multiple chained sibling selectors fa...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://bradclicks.com/cssplay/folding...
Keywords: HasReduction, InRadar
Depends on:
Blocks: 12520
  Show dependency treegraph
 
Reported: 2008-03-05 09:21 PST by Brad
Modified: 2012-03-08 06:17 PST (History)
5 users (show)

See Also:


Attachments
test case (459 bytes, text/html)
2008-03-24 00:43 PDT, Robert Blaut
no flags Details
Test case, similar to Robert's (372 bytes, text/html)
2011-12-19 16:16 PST, HowCool.com
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brad 2008-03-05 09:21:47 PST
The "::checked" pseudo-class selector is supposed to assign a rule based on the "checked" status of a checkbox or radio button. But WebKit only checks the initial attribute in the HTML, and does seem to pay attention to changes that the user makes. The pseudo-class is clearly supposed to reflect whatever the current state is, not just the attribute value at load time. But it doesn't. In the example, you can see the check-mark change on the box when you click on it or click on the label, but the styling does not change in response. Compare this to FireFox or Opera, where the checkbox actually determines the display or not of the nested UL.
Comment 1 Brad 2008-03-05 09:24:29 PST
Also see the radio-button equivalent on this page:

http://bradclicks.com/cssplay/tabs.html

... in which the radio buttons have been left visible in order to illustrate what is happening. Clicking on the tabs (actually labels for the radio buttons) should change the display, as it changes the checked status of the radio button.
Comment 2 Mark Rowe (bdash) 2008-03-17 15:22:13 PDT
<rdar://problem/5803703>
Comment 3 Brad 2008-03-23 18:40:19 PDT
It seems that some progress has been made on this. Now the immediate sibling registers the changes to the "checked" status, but its next sibling does not. So this rule works as the box is checked and unchecked:

li input:checked + label:after {
			content: ' (click to close)'; 
			color:red;
		}

But these do not:

		input + label + ul { display:none; }
		input:checked + label + ul { display:block; }
Comment 4 Robert Blaut 2008-03-24 00:32:16 PDT
Brad, the issue you described is another specific case of problem described in bug 12520
Comment 5 Robert Blaut 2008-03-24 00:43:47 PDT
Created attachment 20001 [details]
test case
Comment 6 Dave Hyatt 2008-04-03 14:14:28 PDT
Yeah this case fails "on purpose" right now, since I wanted to come up with a performant way of doing it.  Ideas include:

(1) Just re-resolve everything after the first changed sibling.  Could result in bad slowness in pages as a result, but then again, people chaining these selectors are kind of asking  for it. ;)

(2) Waste more memory and hold a maximum sibling chain count in the RenderStyles.  This count would enable you to only re-resolve as many siblings as necessary on a change.  Would be faster but RenderStyles would have to grow (making all pages take up more memory).

I'm inclined to just do (1) and not worry about the performance.
Comment 7 Brad 2008-04-03 19:40:54 PDT
Choice number 1 would be better than nothing. What are we talking, maybe an extra quarter second or less after the checkbox is clicked, in an example such as that given? I could see how it might be worse if I had an entire complex page re-render into something vastly different based on the checkbox, but in my example the display property is the biggest change. 

I kind of imagined that the extra memory would only have to be set aside when there were actually sibling selectors in play, in rules that combined them with dynamically updated pseudo-classes (hover also comes to mind). Like maybe you would pre-render screen regions based on what would be needed later with such rules. But I don't really know what I'm talking about when it comes to memory allocation.
Comment 8 cobaco 2011-11-18 04:56:47 PST
This seems to be at least partially fixed now, at least for my testpage:
http://freemen.be/testtabs1.html 
http://freemen.be/testtabs2.html 

both testpages work fine with both:
- safari 5.1.1 (7534.51.22)
- chrome 13.0.782.220
Comment 9 HowCool.com 2011-12-19 16:16:31 PST
Created attachment 119941 [details]
Test case, similar to Robert's

Unfixed as of Chrome 16.0.912.63 (stable) for Robert's and my testcases.