- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sat, 25 Apr 2009 00:03:35 -0500
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style list <www-style@w3.org>
On Fri, Apr 24, 2009 at 11:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Tab Atkins Jr. wrote: >> >> It would work exactly like adding or removing a radio button from the >> DOM, I would think. > > That's not actually that desirable. The behavior of radio buttons is pretty > complicated, has a number of legacy quirks to it, is pretty much > algorithmically slow by design, and differs in different browsers (the above > qualities just describe the parts that different browsers actually agree > on). Gotcha. I threw down some language in a previous email that might work then, at least informally: Whenever an element is clicked/activated/etc, it toggles between matching the :checked pseudoclass and not matching it. (This includes event bubbling.) Whenever an element is made to match the :checked pseudoclass, if it has a string value for the radio-group property, than all other elements with the same string value for radio-group no longer match :checked. >> (I suppose it's possible that it's handled badly, but then that just >> means that radio buttons themselves aren't implemented well and have >> an issue that needs fixing. Again, haven't tested anything.) > > I don't think the interoperable parts of radio button behavior, even the > crappy ones, can be changed without breaking sites. That doesn't mean we > should copy them over wholesale, necessarily. True. ~TJ
Received on Saturday, 25 April 2009 05:04:16 UTC