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

Dmitri,


On Feb 21, 2008, at 11:13 PM, Dmitry Turin wrote:

>
> James,
>
> JE> even if the behavioral part
> JE> isn't provided, the display part would be nice to have.'
>
> OK.
>
> JE> <style>
> JE>      li[state=visible]:focus { visibility="hidden"; }
> JE>      li[state=invisible]:focus { visibility="normal"; }
> JE> </style>
>
> Are you suggesting combination of two decisions:
> 1) some properties for visial view (by the way, let's summarize,
>    what is the difference of tree itself from all other UL),

Properties for visual styles:

[NOTE: I will use folded/unfolded for consistency. Some people have  
suggested collapsed, etc. Any set of words which conveys the states  
needed is fine.]

List-style-type - add tree-view or tree-line or ?
     I'm not sure this is required. If we define line properties,  
icon properties, etc.,
     any list type could have lines connecting peers and subs. (Do  
not believe that I am
     saying this is necessarily a good thing, but some authors might  
want to have numbered
     lists with tree lines, for example. I am just leaving an opening  
for discussion and
     the maximum possible utility of the final CSS styles.)

Line properties -
     line visible/invisible (is this needed? use width=0,  
style=plain, or color=background?)
     line width
     line style (none, plain, dashed, dotted, etc.)
     line color
     line joints/corners (straight, curved, separated, arrows?, etc.)

List icon properties -
     three icons are necessary, to show folded, unfolded, and empty  
sub-trees.

     We could expand the list-style-* properties to allow three images.

     list-style-image - If the list-style-image property order is: 1- 
folded
     2-unfolded 3-empty, then any missing icons will be ignored, and  
look
     reasonable. (If there is no 'folded' icon, whatever icon the  
list-type
     normally uses will be placed. This will be less clear than  
different
     icons for folded/empty/unfolded, but is still possible. The tree  
lines
     will help.)

     list-style-position - needs to be able to place the folded/ 
unfolded/empty
     icons/images inside, outside, or on the joint of the lines.

     Or we could make different properties - list-icon and list-icon- 
position
     (I prefer this option, rather than overload and possibly make  
more complex
     the list-style-* properties.)

     list-icon (folded unfolded empty)
     Three urls could provide the UA with images for these states.  
Missing icons
     are ignored, as stated in 'list-style-image' above.

     list-icon-position (outside/on/inside) Place the list-icon  
outside/on/inside the
     line join position. I will try and show SIMPLE examples, below.  
([I] = icon)

                    |
     outside:   [I] |-----
                    |
     inside:        |-[I]-
                    |
     on:           [I]----
                    |

List layout properties -
List direction - This could be useful for all list-style-types. It  
specifies the layout direction of a list. (For example, in English  
most lists are laid out top-to-bottom, and the subtrees of a list are  
indented to the right.) The default should be the same direction as  
the language layout direction, but this may not be what the author  
needs.  Some lists grow more naturally from bottom-to-top, even in  
English. Some lists (with narrow elements) would fit better in a left- 
to-right layout, with the subtrees either above or below. With the  
list-layout-direction properties, a designer could produce trees with  
peers next to each other and subtrees below, or many other options.  
Needed properties are:

     list-layout-peers (tb, bt, lr, rl) - layout list items which are  
peers from
     top-to-bottom, etc.

     list-layout-subs (lr, rl, tb, bt) - layout list items which are  
sub-trees from
     left-to-right, etc. (This is not clear - what I meant was that  
the indents
     of sub-trees for multiply nested lists will be left-to-right,  
etc. If the
     'peers' and 'subs' properties match, there may be extra space  
between
     parents and children, but no indents are (possibly) needed. See  
'sub-offset')

Sub offset - What if the page author wants the subtrees to be at the  
same indent as the parents? (Assuming there is some other way to  
differentiate the parents from the children: list icons, outline  
numbering, or text color, for example.) The author sets the offset  
value, and sub-lists are offset by this amount, whether they are  
offset left-to-right (indented), right-to-left (in English,  
outdented?), top-to-bottom, or whatever. If the 'peers' and the  
'subs' directions match, this offset provides a visual clue that the  
different lists are a different levels of nesting.

Finally, an option to enable/disable the connection of lines to sub- 
trees. This would allow authors/designers to have sub trees  
'surrounded' by the lines of the parent trees. I see this option  
being very useful when CSS finally specifies collapsing/expanding for  
elements other than lists.

     list-sub-connect- yes/no Draw list-tree-lines to sub-trees or  
only to current list.

> 2) mandatory two lines, proposed by you
> ?
>
> What's about second decision itself, i would prefer some attribute
> for UL, which enter the same behaviour (what you are proposing in
> two lines).

What I was trying to suggest (and didn't do very well) was that a CSS  
author could provide styles that told CSS what to do with folded/ 
unfolded lists when the user 'selects' one of the nodes. My (very  
poor) example intended to say 'if the list element has a hidden sub- 
list and the user selects it (with the mouse or the 'enter' key, for  
example), then the sub-list should be displayed. If the list element  
has displayed sub-list(s) and the user selects it, the sub-list  
should be hidden.

>
>
> Dmitry Turin
> HTML6     (6. 5.4)  http://html60.euro.ru
> SQL5      (5.11.3)  http://sql50.euro.ru
> Unicode7  (7. 2.1)  http://unicode70.euro.ru
> Computer2 (2. 0.2)  http://computer20.euro.ru
>
>

I am still thinking about the behavioral properties for folding/ 
unfolding. If these are carefully considered and presented, they may  
apply to more than just lists. Other responses in this thread, and a  
spun-off thread about 'collapsing' show several people thinking about  
how useful these behaviors can be.

To state my preferences: I believe that folding/unfolding behaviors  
are clearly stylistic and need to be in CSS. I would like to have  
these behaviors apply not only to lists (especially lists with tree- 
lines), but to many other element types.


James Elmore

Received on Friday, 22 February 2008 18:36:30 UTC