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

Re: Tabbed Interfaces in CSS

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 20 Apr 2009 10:06:08 -0700
Cc: www-style <www-style@w3.org>
Message-Id: <C35CB2DF-1B38-4B9E-BD26-905F76C79AB4@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Apr 20, 2009, at 9:23 AM, Tab Atkins Jr. wrote:

>> Using
>> the sibling selector and having the hide the radio buttons is a bit  
>> of a
>> hack, but the use of "::checked" is not so bad in my view. At the  
>> OS, a tab
>> is just a special kind of radio button anyway. And even on HTML radio
>> buttons and checkboxes there is usually no visual checkmark (it is  
>> usually a
>> cross or dot for inputs that have them, but it depends on the OS  
>> and UA).
>> Rather, "checked" just means that there is another state for the  
>> element
>> that indicates something like "on" (as in "on/off"). The "checked"  
>> state
>> seems like a reasonable thing for other elements (such as "label",  
>> or some
>> sort of new "tab-box" or "display:tab-box" element that the label  
>> is part
>> of, or even for arbitrary elements that could be styled or not  
>> depending on
>> their binary state which "checked" indicates).
> Possibly, but there are further questions raised by this.  Frex, would
> clicking on an element alter the :checked state for all ancestors of
> the clicked element as well?

Do you mean because of event propagation? I think probably not, unless  
there was some compelling reason for it to do so. But maybe. I'd have  
to give that some more thought.

> (I agree that the theoretical use of :checked isn't a hack - it's the
> use of a hidden radio button that is.)

Yes, that smells a bit hackish, but is allowed by CSS. Having an  
element maintain its own binary "checked" state would certainly be  

>> In my view, any element should be able to have a second state of  
>> "checked"
>> based on if it has been clicked on an odd or even number of times,  
>> just as
>> it can have a second state of "hover" based on if the cursor is  
>> over it or
>> not. Then you just need a way to indicate default state and radio  
>> grouping
>> (default state would probably require that any element can have  
>> 'checked'
>> attribute in the HTML). Which group (of tabs or radio buttons) an  
>> item
>> belonged to go be indicated by some sort of unique identifier on  
>> the element
>> ('tab-group:a'), which would also indicate that only one item with  
>> that same
>> property value could be checked at a time.
> That would be interesting.  Is there a good use for this outside of a
> tabbed layout, though?

Accordions. Modal windows (the opener could be its label and the close- 
box a separate element of the same group... or vice versa). Almost  
anything where you might currently be using 'onclick' to show or hide  
something by changing a class or 'display' style.

>> If approached this way, then any element could become a tab card  
>> (with a
>> :checked state), and the label could be a regular LABEL element  
>> that exists
>> within it (to switch the :checked state).
> It wouldn't allow you to have multiple tabs associated with the same
> card, though.  Or, rather, it wouldn't correctly style both tabs (the
> one you just clicked would be :checked, but the other wouldn't
> necessarily be).

It could if the LABEL element was the parent or ancestor of the  
multiple elements, or if the "for" attribute of the label attribute  
could accept multiple IDs (a comma-separated or space-separated  
list?), or if you didn't mind having the other elements as children of  
the first (positioned, perhaps). Is this an important feature?
Received on Monday, 20 April 2009 17:06:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:28 UTC