Re: [CSS3] Collapsing elements proposal [wasRe: Collapsing elements]

On Feb 22, 2008, at 12:22 PM, Andrew Fedoniouk wrote:

>
> Daniel Glazman wrote:
>>
>> Andrew, I just cannot read messages whith three or four level
>> of quotation... Could you please send us a detailed and complete
>> proposal for tree-like rendering ? Gather everything and let's
>> discuss it.
>>
>> </Daiel>
>>
> First of all, initial proposal to add list-style-type: tree-line  
> value is
> not related to  collapsing per se.  It can be used for styling
> of static lists too. See two lists at the bottom of [1].
> I propose to allow outline-color and outline-style to style appearance
> of such tree outlines.

Did you see my idea for styling the "::marker" pseudo element?[1] The  
basic idea was that if we had a "tree" list style type, in which a  
transparent rectangle automatically stretched upwards to meet the LI  
above it of the same level, then that rectangle could be styled with  
whatever border or outline (style, width, color) you wish (only the 2  
sides of the rectangle would exist to accept it) without inventing  
new line types. You could even use border and border-radius to give  
it a round corner. You could use width to set the width of the  
rectangle (and thus the tree lines), as well as setting margin, etc.  
as per the CSS3 "::marker" proposal [2]


> --------------------------
> My proposal is to add  :collapsed and :expanded state flags for the  
> DOM
> elements (and correspondent pseudo-classes in CSS)
>
> Here are couple of examples of real life cases where these states  
> are needed:
> 1) Collapsible/expandable lists.
> 2) Tab views (a.k.a. stack views). Set of panels where all panels  
> are in collapsed
> state except of one - current panel.

This is another example where 'checked" really makes sense, as both  
an HTML attribute, and as something that changes when you click on  
it, just like a radio button. In Mac OS X, tabs as an interface  
element are just a subclass of radio buttons. We think nothing of  
saying that a radio button is "checked", but they got their name from  
the old car radios in which only one button could be pushed in at a  
time. There was no check mark involved, just an indication of which  
one had the activated state. That is really the same thing with tabs;  
only one can be the activated one at a time, and it is not indicated  
by an actual check mark.

> 3) "Read more..." views where DOM element in collapsed state show  
> part of
> text and in expanded state this element shows full content.
>
> Such :collapsed and :expanded states should be modifiable by  
> methods of
> DOM::Element interface. (There are other flags that makes sense to  
> enable
> this way, e.g. :checked and :current).

Ideally your state should be something that the author could indicate  
the default state on, the way they can with checkboxes and radio  
buttons can be by including the "checked" attribute. Then it could  
also be set by clicking on it or via JavaScript, the same way that  
"checked" is.

Even if you didn't call it "checked" (I think "checked" is as good as  
any other, and no more overloaded than it is for radio buttons), if  
you made it operate the same then it would be intuitive to set and  
change. The general state changing behavior is already there for  
checkboxes and radio buttons.

Imagine the following uses of the existing nomenclature, at least as  
a model, if not as the actual words to use:

> 1) Collapsible/expandable lists.

	<ul type="tree" checked value= "Macintosh HD">
		<li>System</li>
		<li>Users
			<ul type="tree">
				<li>Me</li>
				<li>Shared</li>
			</ul>
		</li>
		<li>library</li>
		<li>Applications</li>
	</ul>

Clicking on it would automatically change it between its two states  
(like a checkbox), and it would pick up that behavior by the fact  
that it was of type "tree" (or whatever we end up calling it). You  
could have CSS for the "checked" state, and for its not checked state  
to declare its height or visibility or whatever. The UA style sheet  
would be something like this:

	ul[type=tree] { visibility: collapsed; }
	ul[type=tree]:checked { visibility:  visible; }

If you didn't want the behavior, but did want the list type, you  
wouldn't bother with the extra HTML attributes, but just use "list- 
style-type: tree" in the CSS, and optionally style the marker pseudo  
element beyond its simple default.

> 2) Tab views (a.k.a. stack views). Set of panels where all panels  
> are in collapsed
> state except of one - current panel.

Same sort of markup, except that it would have a different type  
attribute (type=tabset, perhaps). So instead of having a list with  
checkbox-like behavior, it would be a list with radio-button-like  
behavior. The "checked" state would be on the LI to indicate it was  
the tab "in front".

	<ul type="tabset">
		<li checked>Tab 1
			<div>
				Contents that is shown because Tab 1 is "checked".
			</div>
		</li>
		<li>Tab 2
			<div>
				Contents that would be shown if Tab 2 was in front ("checked"  
attribute set, or clicked on).
				Contains a second tabset inside it.
				<ul type="tabset">
					<li>Tab A
						<div>
							Contents that would be shown if Tab A was in front.
							Tab 1 would also have to be in front.
						</div>
					</li>
					<li>Tab B
						<div>
							Contents that would be shown if Tab B was in front.
							Tab 1 would also have to be in front.
						</div>
					</li>
				</ul>
			</div>
		</li>
		<li>Tab 3
			<div>
				Contents that would be shown if Tab 3 was in front.
			</div>
		</li>
	</ul>

Default style sheet would have something like this:

	ul[type=tabset] li { appearance: tab-inactive; }
	ul[type=tabset] li:checked { appearance: tab-active; }
	ul[type=tabset] li > div:first-child { display: none; }
	ul[type=tabset] li:checked > div:first-child { display: block;  
appearance: tab-box; }
>


Actually, if the appearance stuff was available, some clever person  
could probably figure out a way to create a tab panel with just  
existing radio buttons and labels, and maybe a level or two of spans  
inside the labels (and maybe a P or fieldset to line everything up  
inside of). That'd be an interesting challenge, even without the tab  
appearance availability. It seems doable on the face of it.

> 3) "Read more..." views where DOM element in collapsed state show  
> part of
> text and in expanded state this element shows full content.

That one doesn't sound like a list, but I could still imagine some  
pairing of "checked" and a type attribute to accomplish it.

These are all examples of things that you want to give binary states  
to, activated by a click (or keyboard equivalent) or by javaScript,  
or by the HTML author declaring which of the two states it would  
start out in. Which is exactly what "checked" does. You could call it  
something else if you like, but you wouldn't have to re-invent the  
wheel. Radio buttons got "checked" because of the behavior of state  
changing that they shared with checkboxes, which is the same behavior  
we've been describing. The state is not called "last-pushed" or  
anything that you would associate with the station preset buttons on  
a car radio, because we already had "checked" to describe the  
changing to a set state from an unset state. it makes sense to me to  
carry that over also to the similar state changes for the examples  
you sited.

> Probably as:
>
> interface Element {
>  ...
>  void setState(enum ELEMENT_STATE state, bool onOff);
>  bool getState(enum ELEMENT_STATE state);
> }
>
>
> Behaviors. [optional but desirable section]
>
> I propose to add (or to extend for those UAs that already support  
> this attribute)
> attribute "behavior" that accepts one of predefined values:
>
> behavior: checkbox | radio | select | multi-select | stack-tab | etc.

I kind of like the idea of presentational behaviors in CSS. I'm not  
sure I followed everything you said, because it is late and my  
eyelids are drooping, but it sounds interesting. It might be easier  
than adding attributes to HTML.


>
> === behavior: checkbox ===
>   when set will make the element:
>   a) focusable and
>   b) onClick event will set/reset :checked state of the DOM element.
> Pretty much the same of what does code behind <button type="checkbox">
>
> === behavior: radio ===
>   will mimic behavior of code behind <button type="radio"> - will
>   set/reset :checked state for the group of elements with the same  
> @name value.
>
> === behavior: select ===
>   will make the element
>   1) focusable and
>   2) will handle navigational keys UP, DOWN, HOME, END and
>       set :current state flag for contained elements with  
> role="option".
>       :current element should be scrolled into the view if needed.
>   3) will handle navigational keys LEFT, RIGHT and set :collapsed
>       and :expanded state for nearest parent having role="option- 
> group"
>       of :current element.
>   4) will handle mouse events correspondingly, e.g. DOUBLE_CLICK
>       will trigger :collapsed  :expanded  state of nearest  
> role="option-group"
>       element.
>
> @role attribute auto-assignment:
>      All list item elements (e.g. <li>) are treated as is if  
> role="option" is defined
>      for them.
>      All contained list elements (e.g. <ul>, <ol>) with first sub- 
> element of type
>      <caption> are treated as if role="option-group" is defined for  
> them.
>      (Such auto-assignment could be done also through @role *CSS*  
> attribute)
>
> Example:
>     <ul style="behavior:select">
>           <li>First terminal node</li>
>           <li>Second terminal node</li>
>           <ul><caption>Third node: option group</caption>
>                 <li>Terminal node 3.1</li>
>                 <li>Terminal node 3.2</li>
>           </ul>
>     </ul>

A caption for a list like that is interesting. That's not currently  
part of HTML either though, is it?


>
[1] http://lists.w3.org/Archives/Public/www-style/2008Feb/0236.html
[2] http://www.w3.org/TR/2002/WD-css3-lists-20021107/#markers