Re: Collapsing elements

Brad,

On Feb 25, 2008, at 9:57 AM, Brad Kemper wrote:
> On Feb 24, 2008, at 8:34 PM, James Elmore wrote:
>
>> 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.
>>
>
> As a follow-up, just to be clear, I do not believe CSS should be  
> used to create or control the states, only to style them.

Sorry that I wasn't clear. I am speaking about styling elements. The  
'states' I mentioned should have been in CSS terms rather than HTML  
terms. For example, CSS already has 'visibility:collapse;' and  
'visibility:visible;' which would be equivalent to collapsed and  
expanded. Right now, 'collapse' only applies to 'dynamic row and  
column effect in tables.' (See CSS 2.1, Section 11.2) What needs to  
be done is to expand the definition of collapse (in CSS) so it works  
with elements other than parts of tables. I am trying to produce a  
reasonably complete model of what that definition might be, looking  
at the current discussion, and looking toward what might be desirable  
in the future. (This planning for the future includes what the HTML  
groups might want/need for new or refined HTML elements. CSS stylings  
of possible HTML expansions will still need to consider the  
possibility/utility of allowing expanded/collapsed elements,  
especially nested elements.)

> HTML already has a way to create and control a binary state. "Type"  
> is used to create a 2-state, click-changeable input ("type=checked"  
> and "type=radio"), and "checked" is used to indicate which of the  
> two states it should start out as. Without the "type", there is  
> already a "non-of-the-above" state.

Right now, if I am reading the HTML spec correctly, 'type' only  
applies to form <input> elements. If your proposal is accepted, that  
means a change in HTML, not a change in CSS.

I am not disagreeing with you. Using 'type' might make sense as an  
overall solution to providing the ability to have states which CSS  
can control. I liked your suggestion of using <select> elements  
(again a part of forms) to create the nested structures for future  
collapsable outlines/menus and using CSS to control that collapse/ 
expansion. I am just trying to be careful and keep the discussion of  
changes to HTML separate from changes to CSS. (I have been 'dinged'  
often in the past for not being careful about this separation; it  
makes sense to do so most of the time.)

> Even if we don't use the same words, at least we have a good,  
> workable model, that would assist in easy understandability of  
> similar state changing mechanisms that can be styled with pseudo- 
> class selectors.

Right. There is no need to reinvent the wheel. The ability to create  
a 'drop-down' menu is very similar to the ability to collapse/expand  
an element. It may be that the solution has already been found and  
implemented, and the CSS group only needs to point that solution out  
and have it apply to more elements. (This would be similar to my  
suggestion of using 'visibility:collapse;' for more than just table  
rows and columns.)

Just be careful to keep the HTML elements separate from the styling  
of those elements. This has been one of my personal peeves for a long  
time, starting with tables, which have many built-in styling  
abilities not found anywhere else. So tables have been used to STYLE  
web pages, since there is no way in either CSS or HTML to do many of  
the things authors/designers want, outside of tables.


James Elmore