Re: Tabbed Interfaces in CSS

On Sat, Apr 25, 2009 at 12:17 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Tab Atkins Jr. wrote:
>>
>> Whenever an element is clicked/activated/etc, it toggles between
>> matching the :checked pseudoclass and not matching it.
>
> OK, what happens if an element that already matches that pseudoclass is
> inserted into the document and is in a radio-group in which something else
> is already checked?

You mean creating an element which is pre-:checked?  I don't think
that's possible.

Or do you mean moving a node from one document to another, where it
matched :checked in the first document?  I would be perfectly fine
with saying that it's not :checked when moved to the new document.
Are there any weirdnesses that I'm overlooking that would cause
problems here?

> Or has its radio-group property changed, with the same
> effect?

This is the interesting problem.  I'm fine with taking the easy way
out.  Whenever radio-group changes, the element becomes un:checked.
Some cursory thinking doesn't show this as causing any problems.  I
basically want :checked to change *only* as a result of direct user
interaction, not due to some crazy conflict-resolution rules.

(The closest thing to 'crazy confliction-resolution rules' I'd
tolerate is, say, making an entire ancestor chain have the same
radio-group value, then clicking the innermost child.  The click event
would bubble up the chain, making each parent :checked in turn and
removing :checked from the child, leaving you with just the outermost
element :checked.  That's easy for authors to understand in terms of
clicks, though.)

~TJ

Received on Saturday, 25 April 2009 05:33:08 UTC