Re: Collapsing elements

On Feb 24, 2008, at 8:34 PM, James Elmore wrote:

> Brad,
>
> On Feb 22, 2008, at 10:15 AM, Brad Kemper wrote:
>
>>
>> On Feb 21, 2008, at 10:31 AM, Bert Bos wrote:
>>
>>>> But rather than invent a new state and pseudo-class, I would rather
>>>> see "checked' repurposed for this type of list, and given a
>>>> definition to mean open if checked and closed if unchecked.
>>>
>>> My intuition says that overloading ':checked' is dangerous and  
>>> not very
>>> intuitive. In the examples I gave so far there is nothing that I  
>>> would
>>> associate with putting a check mark. It's collapsed, expanded,  
>>> toggled,
>>> set to an alternative state, set to a second state, maybe changed or
>>> restored, but not checked...
>>
>> I see checking an element as meaning you are marking it in some  
>> way to indicate a second state for it, but not necessarily a  
>> visual mark. The "checked" attribute on an HTML checkbox or radio  
>> button means that it has been given this second state, instead of  
>> the default state that everything else has. It doesn't look like a  
>> check mark in most OS's radio buttons, and even if I make the  
>> checkbox invisible, its label can still change it to or from this  
>> second state.
>>
>> So, to me, "checked" is perfect, because it allows you to have the  
>> regular styling in one rule, and the styling for a second binary  
>> state in another, regardless of how it got marked to achieve that  
>> second state. With checkbox and radio button buttons, that state  
>> can be set initially with an element attribute (checked). With a  
>> collapsing UL it could presumably be thus marked as having that  
>> second non-default state with JavaScript. But consider if an  
>> actual functional collapsable UL was added to HTML, with something  
>> like <UL type="tree">. In that case, its initial state would not  
>> necessarily be open or closed, collapsed or expanded, but could be  
>> set with another attribute, like checked:  <UL type="tree"  
>> checked>. It seems to me that you would need an attribute like  
>> checked as part of the DOM, so that it could be set via JavaScript  
>> or non-scripted HTML, and so a click could change that state.
>>
>
> This might be the easiest way to define 'states' for collapsing and  
> expanding elements, but I think I agree with Bert on this one. My  
> mind is working on what the ability to have states for an object  
> might mean, and how I could use CSS to control those states, and it  
> seems to me that there is, almost certainly, more than one state  
> needed. (Actually, more than two states, more than just 'checked'  
> and 'unchecked'). At the very least, there needs to be 'collapsed',  
> 'expanded', and 'none of the above' - which means there is nothing  
> to expand or collapse.

I don't think so. The "unchecked" states already exist and can be  
styled. Adding "checked" would allow you to create a second state  
that could be styled. "None of the above" means that you simply do  
not add a checked attribute and you do not share the same class as  
the one that deals with 2 states.

> For the most basic outlines, where there might be nested levels  
> underneath, any or all of which might be collapsed or expanded,  
> this is the minimum needed. Even better would be: collapsed,  
> expanded 1 level, expanded n levels, no expansion possible.

Nesting is very simply done with the nesting of the HTML structures.  
If it is "type=tree" that created the first level of the collapsible/ 
expandable tree (on a UL, let's say), then "type=tree" on its  
children (child ULs) would create nested trees of the same sort, each  
of which would also have a checked or default state.

Look, if you want to have the state information recorded somewhere  
without using JavaScript, then it is not a purely CSS solution. You  
need to use attributes in the HTML, so that the author can set the  
initial state on a case-by-case basis (this tree branch of the tree  
is initially collapsed, this one is expanded). With checkboxes and  
radio buttons this is done by adding the word "checked" as an  
attribute to the HTML of that element. You also need to identify  
which elements can have the new state information (changeable with a  
click or keyboard action). With inputs, this is done with  
"type=radio" and "type=checkbox". It also provides some default GUI  
controls for changing the state and a label that can also change the  
state.

So the question is, should we follow this same model? I say, "yes",  
as it is simpler that way. Even if you don't actually use the word  
"checked", you could still have an HTML attribute like  
"type=collapsible" or "type=tree" (analogous to "type=checkbox") to  
indicate that it is an item with two changeable states, and then a  
different attribute to tell it the initial state. I prefer "checked"  
for that second attribute, because it is something I am already  
familiar with for doing this kind of state change (which already  
works on two different input types), but it could be  
"collapsed=expanded"/"collapsed=collapsed".

A different way to go would be just one attribute with three values,  
"collapsed=expanded"/"collapsed=collapsed"/"collapsed=non- 
collapsable", which seems awkward. Or alternately just have the  
presence of the "collapsed" attribute indicate that it can have the  
two states, and have the two different values determine the initial  
state. I still prefer the checkbox/radio button model for its  
familiarity.

To do everything in CSS is more complicated. You need a property to  
indicate that it is an object is something that can be clicked on to  
change its state, which would be like defining a checkbox, radio  
button, or anchor using nothing but CSS. It is unprecedented. Then  
you need to style it to indicate it can be clicked on to change its  
state. Then you need a property to indicate its state. Then, in 2  
separate rules, you need to style those two states. So the selectors  
on those two rules are based on the state information carried in a  
previous rule, which is also unprecedented, and would certainly  
complicate the cascade. What if in the "LI:expanded" rule you changed  
the "expandable-collapsable" property to say it is not something than  
can be expanded/collapsed"? Or if, in your example, if the  
"LI:expanded" rule included "expandable-collapsable:none-of-the- 
above"? No, this really calls for html attributes to change states,  
and we have an example of just this sort of thing with "checked".

> For things which are not outlines, such as thumbnail and full-sized  
> images, where the expanded images might have expandable sections,  
> the process of expansion could be even more complex. (Sorry about  
> the denseness of the description, I will try an example.)
>
> Example Use Case: Business web site with expandable images and  
> collapsed information.
>
> Start: an image of the business, with a label/title/caption stating  
> the name/products. User clicks on the building.
>
> The building shrinks, but the same area is still needed, because  
> now the business address is listed next to it. User clicks on the  
> address.
>
> The address shrinks and a map showing the location of the business  
> is shown below the address. User clicks on the title of the business.
>
> The title moves to the side and shows a menu of options as in a  
> normal web site: people, products, statement of purpose, etc.  
> appear. User clicks on the building thumbnail and a new image  
> appears which shows the inside of the building.
>
> All this information might be easily placed in a single HTML file  
> and displayed on a single (complex) screen, but it is better if  
> some of the information / images are hidden until actually needed.  
> I could, surely, produce a web site with multiple pages to do  
> everything I described here, but then each HTML file would contain  
> much duplicated information (building image, address, page caption,  
> etc.). I want to have the information available, but kept in a  
> single file with the displaying of different amounts of that  
> information in different places and sizes controlled through CSS.  
> This is one, complex example of expanding and collapsing elements.
>
> <SIDE NOTE> The ability to collapse visually needs to be correlated  
> with the ability to collapse logically, so non-sighted users can  
> still understand and use the information. </SIDE NOTE>
>
> Further, I might want to have a series of images which convey the  
> same or similar information, and have only one shown at a time.  
> This slideshow would probably need not only 'collapsed' and  
> 'expanded', but 'forward' and 'backward' states, so the correct  
> image is shown.
>
> Yes, I can hear the screaming all the way from California. Yes, I  
> can do this right now with Java or JavaScript. But all I care about  
> is the control of the placement of the correct image, why can I not  
> do this with CSS? As long as the basic CSS renderer allows me to  
> show two images (call them expanded and collapsed for simplicity),  
> why not allow me to show three images? Why not four?

If you want this ability on any element, then instead of "type=tree"  
or "type=tab", then you would probably need something like  
"changeable= 2-states", and a current state indicator, such as  
"state=1". Its up to your CSS rules to determine the styling of the  
two different states, and the value of the "changeable" atribute  
would determine. That might be interesting, as it could allow for 3- 
state, 4-state,..n-state changing and styling:

LI[state=1] UL { display: none; }
LI[state=2] UL { display: block; }

#thisImage[state=1] { background-image: url(picture1.png); }
#thisImage[state=2] { background-image: url(picture1.png);; }


>
> If there are CSS properties which overlap cleanly, I am definitely  
> in favor of using them. That is the simplest way But, in this case,  
> I think that 'checked' and 'unchecked' do not overlap very well.  
> (As another counterexample, a web site I visit occasionally has  
> recently added check marks for links that the user has recently  
> visited. This was an aid for colorblind who use the site. It was  
> well received. But, this 'check' would conflict - at least in the  
> mental model - with the use of 'checked' and 'unchecked' for  
> expanded and collapsed elements.)
>
> Please continue the discussion. If we can propose most of the  
> necessary CSS properties and DOM elements for a collapsing and  
> expanding ability in CSS, we will be well ahead.
>
> James Elmore
>
>