W3C home > Mailing lists > Public > www-style@w3.org > February 2008

Re: Collapsing elements

From: Brad Kemper <brkemper@comcast.net>
Date: Mon, 25 Feb 2008 22:15:42 -0800
Message-Id: <4D1BAF4A-72D4-49E2-929A-1D807E57D10F@comcast.net>
Cc: www-style mailing list <www-style@w3.org>
To: James Elmore <James.Elmore@cox.net>

On Feb 25, 2008, at 11:41 AM, James Elmore wrote:

>> 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.

Correct. My point is that HTML is best suited to carrying the state  
information, as it does already with checkable inputs. (To try to set  
the state with CSS and then select in CSS based on that state would  
be a path fraught with peril.) So that leaves us with using existing  
checkable elements (radio and check-boxes), or else changes to HTML  
to allow other elements to be checkable and to be able to set their  
state to checked (or not). it is "type" that makes inputs checkable,  
but it could be some other attribute as long as we are changing.  
Conceivably, it could be <div checkable checked> instead of <input  
type="tab" checked>.


> 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.)

I understand. It would seem to require a joint effort, unless we use  
existing elements that carry state information (existitng elements  
that can be "checked"). Or unless CSS decides that labels can reflect  
the "checked" state of their associated inputs.

>> 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.

I agree. That seemed to be one of Andrew's conceptions as well.

> 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.)

That would prevent "::outer" from being visible though, wouldn't it  
("outer" inherits from its insides, because that is its real parent)?  
Does it have any advantage over { height:0; overflow:hidden; } other  
than not having to hide its descendants too?

> 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.

I agree totally with every sentence in that paragraph. Which is why I  
am less favorable towards something like <div type="collapsible"  
expanded> (since those words imply a certain styling), and more  
favorable towards <div changeable=" 2-states" state="1"> or <div  
states=" 2" initial-state="1">, which could be styled in any way you  
wish. That would be much more of an abstract state for the element to  
carry, but could conceivably be carried by anything (except possibly  
form elements and anchors, that handle clicks and keyboard  
activations on their own, and would be thus difficult to change other  
states on by user action).
Received on Tuesday, 26 February 2008 06:15:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:01 GMT