Re: [CSS3] Proposal to add list-style-type: tree-line value

On Feb 20, 2008, at 3:12 PM, Andrew Fedoniouk wrote:

> If you speak about first <select> on the picture:
> http://www.terrainformatica.com/htmlayout/images/tree-view-lines.png
> then yes, I do have CSS flags that define folded state.
>
> :expanded and :collapsed flags (and pseudo-classes).
> Behavior (code behind particular widget (DOM element)) just sets/ 
> resets them.
> And CSS does the rest.
>
> That <select> is defined as:
>
>  <select>
>    <options expanded>Metals
>      <options expanded>Alkaline Metals
>        <option>Lithium <code>Li</code></option>
>        <option>Sodium <code>Na</code></option>
>        <option>Potassium <code>K</code></option>
>      </options>
>      <options expanded>Transition Metals
>        <option>Scandium <code>Sc</code></option>
>        <option>Titanium <code>Ti</code></option>
>        <option>Vanadium <code>V</code></option>
>      </options>
>    </options>
>    <options expanded>Halogens
>        <option>Fluorine <code>F</code></option>
>        <option>Chlorine <code>Cl</code></option>
>        <option>Bromine <code>Br</code></option>
>    </options>
>  </select>
> And style looks like:
>
> select options:collapsed > :not(:first-child)
>            // normally all items inside options are hidden
>            // except the very first one - it is a caption of the  
> option group
> {
>    visibility:collapsed;
> }
> select options:expanded > option,
> select options:expanded > options // but in expanded state  
> allsubitems are shown
> {
>    visibility:visible;
>    display: list-item;
>    list-style-type: tree-line;
>    outline-color:red;
> }

Andrew, you began by talking about list-style-type for a tree view,  
but you seem to imply that it could be used with a SELECT menu, not  
just a traditional list.

It is pretty interesting to think of a SELECT menu as just a special  
kind of list, one in which each option is like an "LI" that behaves  
like a radio button. If that were the case, then "list-style-type"  
could make it into a tree list, some pseudo-classes and state  
information could make the tree folded or expanded, and "appearance:  
pop-up-menu" could make it more like a traditional SELECT.

I would rather see "optgroup" with labels used instead of the non- 
standard "options". One OPTGROUP within another (not currently  
allowed in HTML 4.1, AFAIK) would create multiple nestings of tree  
branches if the SELECT is acting as a tree view control, and in a  
traditional SELECT pop-up menu would further indent or could even  
conceivable act as hierarchical sub-menus.

This would be a good way of bringing fuller stylability to SELECT  
menu options, if SELECTs, OPTGROUPs, and OPTIONs could be styled  
using all of the CSS that can be applied to UL/OLs, nested UL/OLs,  
and LIs. Conversely, if a SELECT is a kind of list, then any list  
full of option buttons could be turned into a SELECT via CSS.

For instance, if I wanted a list to behave as a SELECT (not including  
its radio-button-like features), I should conceivably be able to do  
this:

	UL { appearance: pop-up-menu; }

The following (typical OS-common styling) would be included in the  
UA's style sheet for this appearance (includes "active" pseudo-class  
to work with UL, and some suggested new appearances), but could be  
overridden by the author (or user) by using the same selectors:

	UL::outside, SELECT:not([size]), SELECT[size=1] {
		/* closed pop-up */
		content: attr(title);
		position: relative;
		/* color, etc. for the default, closed "SELECT" element */
	}
	UL {
		/* the menu itself, before being revealed */
		height: 0; overflow:hidden;
		/* can't use "display:none" because */
		/* it would also hide the "::outside" elements */
	}
	UL:active, SELECT:not([size])::choices , SELECT[size=1]::choices {
		/* (open pop-up menu) */
		/* (for "::choices", see [1]) */
		appearance:menu-list;
		position:absolute;
		height: auto;
		/* Actual position and height and overflow  */
		/* would be UI-specific when this appearance is used,  */
		/* or the author could override. */

		/* Scrolling mechanism for this appearance is OS-specific:
		/* (top/bottom triangles on Mac, tiny scrollbars on Windows,  
etc. ). */
		/* Some non-Mac OS's would use max-height to get a scroll-bar */

		/* Open menu for this appearance can extend beyond the window */
		/* as normal open menus do, but should then */
		/* ignore author changes to width, position,  */
		/* negative margin, etc., to avoid chrome spoofing */
	}
	UL LI, SELECT OPTION { appearance: menu-item; }
	
	UL:active UL, OPTGROUP {
		appearance: option-group;
		height: auto;
		/* "margin-left" or "padding-left" or "left" to handle left offset  
according to OS UI */
	}	

	UL:active UL:before {
		appearance: menu-divider;
		/* some element with a single border as per the OS UI */
	}
	UL UL[title]:before, OPTGROUP[label]:before {
		content: attr(label), attr(title);
		appearance: option-group-label;
	}

Colors, padding, borders, etc. could be specified on the LI's, but  
would default to those provided by the OS appearance (or you could  
use "appearance:normal" if you wanted to roll your own). To make each  
embedded UL (option-group equivalent) into a hierarchical menu, the  
author could add the following:

	UL UL, SELECT:not([size]) OPTGROUP, SELECT[size=1] OPTGROUP {
		appearance: sub-menu;
	}
	UL:active UL:before,
	SELECT:not([size]) OPTGROUP:before,
	SELECT[size=1] OPTGROUP:before {
		content: attr(label), attr(title); appearance: sub-menu-opener-item;
	}
	UL:active UL,
	SELECT:not([size]) OPTGROUP,
	SELECT[size=1] OPTGROUP {
		height: 0; overflow:hidden;
	}
	UL:active UL,
	SELECT:not([size])  OPTGROUP::choices,
	SELECT[size=1] OPTGROUP::choices {
		height: auto;
		position:absolute;
		/* "top" and "left" for sub-menu appearance is OS-specific */
	}

If you had all of the above, then for radio-button-like features in a  
list that is styled as a SELECT, you could do this;

<UL>
	<LI><LABEL><INPUT type="radio" name="menuchoices" />Choice 1</ 
LABEL></LI>
	<LI><LABEL>INPUT type="radio" name="menuchoices" />Choice 1</LABEL></ 
LABEL></LI>
	<LI><LABEL>INPUT type="radio" name="menuchoices" />Choice 1</LABEL></ 
LABEL></LI>
</UL>

Then, instead of styling the LI as the menu item, you would style the  
label as the menu item:

	UL LABEL { appearance: menu-item; }

The UA would then automatically use use a menu-style check-mark  
(instead of a traditional radio button look) for any checked radio  
button within any element with a menu-item appearance (and a blank  
area for the unchecked state). If authors didn't want to use the OS  
appearance for the menu item, or wanted to override the appearance of  
the check-mark, then they would need to know how create their own  
check marks by re-styling the radio button. It would be fairly easy,  
if the UA had a built in style sheet for radio buttons like the  
following:

	input[type=radio] { background: transparent url(radiobutton.png) no- 
repeat; width:12px; height;12px; }
	input[type=radio]:active { background-image: url 
(radiobutton_pushed.png); }
	input[type=radio]:checked { background-image: url 
(radiobutton_checked.png); }

Then you could imagine the following for SELECT OPTIONs:

	SELECT OPTION { background-image: none; width:12px; height;12px; }
	SELECT OPTION:checked { background-image: url(checkmark.png);   }

So if you wanted the above HTML to be styled like a menu item, you  
could do this:

	UL LI input[type=radio] { background-image: none; }
	UL LI input[type=radio]:active { background-image: none; }
	UL LI input[type=radio]:checked { background-image: url 
(checkmark.png); }
	UL LI input[type=radio]:checked:active { background-image: url 
(checkmark.png); }


[1] http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-choices