Re: Collapsing elements

Brad Kemper wrote:
> I don't want to diminish the usefulness of being able to create a 
> tree-like list simply by setting the list-style-type (or being able to 
> style the "::marker" to set color, width, line-width, dotted, etc. of 
> the line), nor of being able to set presentational behaviors (such as 
> checkbox-like behavior) to any element. I do believe that checkbox-like 
> behavior is what is needed in order to change between states for a 
> collapsable list, just as radio-button-like behavior is what is needed 
> in order to change between states of a tabs panel.
> 
> To illustrate this point, I've created a working collapsable tree list 
> that uses already implemented features of CSS3. Instead of using a 
> list-style-type, it has generated content to create a small, 
> absolutely-positioned block to the left of each LI, and this small block 
> has two border edges. Each LI also has a left border edge that the small 
> box aligns with. For the collapsing/expanding behavior, each UL is 
> inside an LI, and preceded by a checkbox and label. The ":checked" 
> pseudo-class is used with adjacency selectors and the label to set the 
> display of the UL when the user clicks on the label (or when the author 
> sets the "checked" attribute in the HTML).
> 
> You can see it here, with explanatory notes:
> 
> http://bradclicks.com/cssplay/foldingList.html
> 
> Because of the CSS3, it has varied success depending on the browser you 
> use. FireFox 3 works well (except I had to use a CSS hack to work around 
> the fact that it would not absolutely position the generated content). 
> The shipping version of Opera works well (except that it doesn't 
> understand "last-child", so the lines on the tree-list do not look 
> right). And Safari 3 looks good and handles the selectors correctly (but 
> only with the initial author-set settings: it does not change when the 
> user clicks to change the state of the checkbox).
> 

Sidenote:

   :last-child is an equivalent of :nth-child(-1) in the same
   way as :first-child is an equivalent of :nth-child(1)

   And yet:
    :nth-last-child(1) is also :last-child

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.

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;
}

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.

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. Think about
up/down/left/right keyboard keys handling for example.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 1 March 2008 20:18:00 UTC