W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: Tabbed Interfaces in CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sat, 25 Apr 2009 00:03:35 -0500
Message-ID: <dd0fbad0904242203p2b2ffd47xe20a1833d3f60bf0@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT