17680 2008-03-05 09:21:47 -0800 Combination of checked pseudo-class and multiple chained sibling selectors fails in Webkit 2022-07-12 13:11:49 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) All All RESOLVED CONFIGURATION CHANGED http://bradclicks.com/cssplay/foldingList.html HasReduction, InRadar P2 Normal --- 12520 1 brkemper webkit-unassigned ahmad.saleem792 allan.jensen ap bdakin bfulgham cobaco mitz rniwa webkit oldest_to_newest 72803 0 brkemper 2008-03-05 09:21:47 -0800 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. 72804 1 brkemper 2008-03-05 09:24:29 -0800 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. 74177 2 mrowe 2008-03-17 15:22:13 -0700 <rdar://problem/5803703> 74898 3 brkemper 2008-03-23 18:40:19 -0700 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; } 74947 4 webkit 2008-03-24 00:32:16 -0700 Brad, the issue you described is another specific case of problem described in bug 12520 74949 5 20001 webkit 2008-03-24 00:43:47 -0700 Created attachment 20001 test case 76267 6 hyatt 2008-04-03 14:14:28 -0700 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. 76285 7 brkemper 2008-04-03 19:40:54 -0700 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. 505688 8 cobaco 2011-11-18 04:56:47 -0800 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 524263 9 119941 programming 2011-12-19 16:16:31 -0800 Created attachment 119941 Test case, similar to Robert's Unfixed as of Chrome 16.0.912.63 (stable) for Robert's and my testcases. 1882467 10 ahmad.saleem792 2022-07-12 12:38:41 -0700 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! 20001 2008-03-24 00:43:47 -0700 2008-03-24 00:43:47 -0700 test case test case text/html 459 webkit PCFET0NUWVBFIGh0bWw+CjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+CiAgICBkaXYgeyBib3JkZXI6 IDFweCBzb2xpZDsgaGVpZ2h0OiAxZW07IG1hcmdpbi1ib3R0b206MC41ZW19CiAgICAudGVzdCB7 IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyB9CiAgICAudGVzdCArIGRpdiArIGRpdiArIGRpdiAg eyBiYWNrZ3JvdW5kLWNvbG9yOiBibHVlOyB9CiAgICAudGVzdDpjaGVja2VkICsgZGl2ICsgZGl2 ICsgZGl2IHsgYmFja2dyb3VuZC1jb2xvcjogbGltZTsgfQo8L3N0eWxlPgo8bGFiZWwgZm9yPSJj aGVjayI+dGhlIGxhc3QgZGl2IHNob3VsZCBiZSBibHVlIGFuZCBiZWNvbWUgZ3JlZW4gd2hlbiB5 b3UgY2xpY2sgdGhpcyB0ZXh0IG9uY2U8L2xhYmVsPjxpbnB1dCBjbGFzcz0idGVzdCIgaWQ9ImNo ZWNrIiB0eXBlPSJjaGVja2JveCI+CjxkaXY+PC9kaXY+CjxkaXY+PC9kaXY+CjxkaXY+PC9kaXY+ Cgog 119941 2011-12-19 16:16:31 -0800 2011-12-19 16:16:31 -0800 Test case, similar to Robert's testcase.html text/html 372 programming PCFET0NUWVBFIGh0bWw+CjxodG1sPgogICAgPGhlYWQ+CiAgICAgICAgPHN0eWxlIHR5cGU9InRl eHQvY3NzIj4KICAgICAgICAgICAgaW5wdXQ6bm90KDpjaGVja2VkKSArIGxhYmVsICsgZGl2IHsK ICAgICAgICAgICAgICAgIGRpc3BsYXk6IG5vbmU7CiAgICAgICAgICAgIH0KICAgICAgICA8L3N0 eWxlPgogICAgPC9oZWFkPgogICAgPGJvZHk+CiAgICAgICAgPGlucHV0IHR5cGU9ImNoZWNrYm94 IiBpZD0iaGlkZSI+CiAgICAgICAgPGxhYmVsIGZvcj0iaGlkZSI+U2hvdyBtb3JlIGNvbnRlbnQ8 L2xhYmVsPgogICAgICAgIDxkaXY+VGhpcyBzaG91bGQgYmVjb21lIHZpc2libGUgaW1tZWRpYXRl bHkuPC9kaXY+CiAgICA8L2JvZHk+CjwvaHRtbD4K