Re: Collapsing elements

On Mar 1, 2008, at 12:15 PM, Andrew Fedoniouk wrote:

> Solution with adjacent sibling combinator:
>   input + label + ul { display:none; }
>   input:checked + label + ul { display:block; }
> looks very interesting and cool but it is not always possible
> to put trigger element (checkbox here) near (in terms of DOM position)
> the collapsible target. Think about tabs/stacked elements
> implementation where tabs bar is pretty far in the DOM from
> list of panels it is aimed to switch.

Personally, I think it is pretty natural to have the content for each  
tab adjacent to its label, at least at the HTML code level. That is  
how I set it up in my other demo example for tabs [1]. But I was also  
thinking about how something like "move-to" would be useful there  
also.[2] It would allow you to have the content together with the  
label in the HTML, and then move the content to some other box using  
CSS. You could even use it to move the tabs to the bottom of the box,  
if you wanted.

I'm not a huge fan of the syntax of "move-to" (I'd rather it just  
used existing ID attributes in the HTML, the way innerHTML does,  
rather than create its own system of identifiers), but I like what it  
allows you to do, and it seems like a simpler way to deal with  
translating my demo into something that addresses your concern (once  
"move-to" or whatever it evolves to is supported). Of course, if  
checkbox-like behavior could be assigned to any element, then  
adjacent sibling combinators are not needed.

> One of early ideas was to define @bound-target and @bound-state  
> attributes.
> Having them your sample could use:
> input
> {
>   bound-target: selector( :this + label + ul );
>   bound-state: :collapsed;
> }
> input:checked
> {
>   bound-state: :expanded;
> }

One thing I dislike about using the words "expanded" or "collapsed"  
as pseudo-classes is that they really just seem to describe the  
visual styling (achievable using "display" or "visibility" or "height/ 
overflow", etc.) of an "on/off" type of state. I'd much rather the  
binary state remain an abstract notion with arbitrary meaning, as it  
currently is with checkboxes, and use whatever styling you choose to  
represent those two states. You could even create something like  
Outlook's 2-line message preview by setting the height of the un- 
checked state to be equal to the line-height times 2 (and a fuller  
preview for the "checked" state would be "height:auto; overflow:auto"  
and moved over with absolute positioning into a preview area).

> And some abstract tabbed stack can be defined as:
> input[type=radio].tab
> {
>   bound-target: selector( div.panel:nth-child( @this.index ) );
>   bound-state: :collapsed;
> }
> input[type=radio].tab:checked
> {
>   bound-state: :expanded;
> }
> As you may see I am forced to use some funny things like
> @this.index that is position in the DOM of the element
> this css attribute is applied to. But if you will go in
> this direction you will end up with the need of creation
> of full programming language.

Yes, I'd rather keep it simpler than that. That seems like overkill,  
just to be able to handle having the tab content separated from the  
tab label, something that "move-to" would be able to handle when needed.

> And yet bound-target/bound-state are not solving problems of
> event handling. In case of tree view that we discuss here
> it should be focusable element that support navigation and
> collapsing/expanding by keyboard.

I was thinking that labels were focusable and activate-able via  
keyboard, but that might not be universal. It might mean that for my  
example I would need to keep the actual checkboxes displayed but  
clipped if I didn't want them visible, and use some appearance-styled  
outline on the label when the ckeckbox is checked. Of course, if I  
could assign checkbox behavior directly to the LI, then that should  
also include the keyboard activation that checkboxes currently enjoy  
(using "spacebar", on the Mac, when full keyboard access to all  
controls is turned on in the "Keyboard & Mouse" system preference).

> Think about
> up/down/left/right keyboard keys handling for example.

Having different keyboard access than what is used for checkboxes  
might make sense if the meaning of "collapsed" and "expanded" was  
significantly distinct (beyond the purely visual) from unchecked and  
"checked", enough too warrant different attributes and selectors. Are  
they? Would that have more meaning to a screen reader, for instance,  
causing it to intentionally skip over collapsed elements that it  
otherwise wouldn't? If so, would arrow keys be better than the  
activation key that works on other elements, such as the various  
forms elements?

If there is no semantic (non-visual) difference between "collapsed /  
expanded" and "[default] / checked", or if the screen reader software  
could never be expected to catch up to modern times or to do the  
right thing, then I'd just stick with "checked" to represent the  
alternate state.

> -- 
> Andrew Fedoniouk.


Received on Sunday, 2 March 2008 20:20:58 UTC