Bug 17680

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.

<rdar://problem/5803703>

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

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

Created attachment 20001 [details] test case

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.

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

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.

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!