Combination of checked pseudo-class and multiple chained sibling selectors fails in Webkit

• Component: CSS
• Status: RESOLVED CONFIGURATION CHANGED

[Brad]

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.

[Brad]

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.

[Mark Rowe (bdash)]

<rdar://problem/5803703>

[Brad]

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; }

[Robert Blaut]

Brad, the issue you described is another specific case of problem described in bug 12520

[Robert Blaut]

Created attachment 20001 [details]
test case

[Dave Hyatt]

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.

[Brad]

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.

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

[HowCool.com]

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.

[Ahmad Saleem]

I am unable to reproduce this issue across all three test cases:

1) From URL Field
2) Test Case (original from Robert)
3) Test Case updated by HowCool.com

I am using Safari 15.5 on macOS 12.4. It behaves and remembers user state and keep "radio" button or state checked-in and updates styling immediately.

I think it was fixed along the way and can now be marked as RESOLVED CONFIGURATION CHANGED. Thanks!