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

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

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 28 Mar 2008 21:31:32 -0700
Message-ID: <47EDC624.9070504@terrainformatica.com>
To: dbaron@dbaron.org, www-style <www-style@w3.org>

L. David Baron wrote:
> On Wednesday 2008-02-20 12:56 -0800, Andrew Fedoniouk wrote:
>> I think it makes sense to add another value to the list-style-type 
>> enumeration - "tree-line".
>>
>> So if you have defined something like this:
>>
>> ul > li
>> {
>>   display: list-item;
>>   list-style-type: tree-line;
>>   |outline-color:powderblue;
>> }
>>
>> then you will be able to define lists with tree lines.
>> See two samples at the bottom of:
>> |
>> http://www.terrainformatica.com/htmlayout/images/tree-view-lines.png
> 
> So writing a spec for this is far from trivial.  A spec, for only
> the visual part (ignoring any behavioral aspects, which are likely
> to be out of scope for CSS) is going to have to cover two main
> areas:
> 
>  * how to draw the tree lines/twisties.  There are a bunch of
>    different cases:
>    Twisties for:
>     * tree nodes without children
>     * tree nodes with children, expanded
>     * tree nodes with children, collapsed
>    and then the lines, which need to connect a node to all of its
>    children that are tree nodes.  We would need rules explaining how
>    to draw all of these things (this seems related to the
>    'appearance' property).
> 
>    It's not clear to me whether rules for drawing would satisfy 90%
>    of authors or whether they'd satisfy 10% of authors.  I suspect
>    if the trees looked sufficiently like operating system trees it
>    might satisfy a large enough percentage of authors to be worth
>    implementation in browsers.  But it's not worth implementing
>    something that authors wouldn't use because it doesn't look the
>    way they want.
> 
>  * how to determine what list items are connected with each other.
>    CSS currently has only a concept of list-item, and no concept of
>    list containment.  For example, are list items in a child of a
>    list item a child list of that item?  What about a grandchild?
>    Great-grandchild?  Does it depend whether there are other
>    siblings?  For example, how would you render list-style-type:
>    tree-item on markup like:
> 
>    <ul>
>      <li>item</li>
>      <li>item
>          <h3>A section</h3>
>          <div>
>            <p>Some text.</p>
>            <ul>
>              <li>Is this item connected by tree lines to its
>              great-grandparent?</li>
>            ...
> 
>     The key question here is:  is it possible to come up with rules
>     that work here for 90% or more of cases?  Or will authors need
>     to use selectors to say how their lists work?
> 
> -David
> 

Tree lines are not that complex but rather very simple.

Here is the idea:

Imagine that you have two images with shapes T (rotated 90 ccw) and L.
Imagine that you have a list:

<ul>
   <li>...</li>
   <li>...</li>
   <li>...</li>
   <li>...</li>
</ul>

and styles:

li { list-style-image:url(T); }
li:last-child { list-style-image:url(L); }

Image T (rotated 90 ccw) will be drawn with vertical bar spanning
the whole height of margin box of li. Intersection point will drawn
exactly where you draw bullet now.

For the element with sub list:

<ul>
   <li>...</li>
   <li>Element with sub list
       <ul>
            <li>...</li>
            <li>...</li>
       </ul>
   </li>
   <li>...</li>
   <li>...</li>
</ul>

list image of <li> will have vbar drawn through the whole
height of li connecting it with vbar of previous
and next items.

I think this part is easy and clear. That is really not harder
than to draw simple bullet.

"plus"/"minus" icons are different story/case.

Imagine that you have :collapsed and :expanded
state flags. These flags are getting initialized
for all list elements on load time in the following way:

If some <ul> contains non-zero number of <li> elements then such <ul> 
and its parent are getting either :expanded or :collapsed state flags. 
:expanded if there is @expanded attribute defined and :collapsed otherwise.

If you have this setup then the rest is easy:

li { list-style-type: tree-line; }
li:expanded { list-style-image:url(minus.png); }
li:expanded > ul { display:block; }
li:collapsed { list-style-image:url(plus.png); }
li:collapsed > ul { display:none; }

That is also not so complex I believe.

And here is a variation of the above that I use in my engine.
This is just for information and related to behavioral style
but not to visual style per se.

In my case I have foreground-image so that plus/minus
is getting drawn by foreground-image rather than
list-style-image so I can have list-style-type
and foreground-image drawn on top of it.
foreground-image/foreground-repeat:no-repeat is a special case and
treated as an icon of the element. It gets special type of
mouse event : ClickOnIcon. This event allows to the behavior 
("activator") attached to the list to handle it and switch 
:collapsed/:expanded states. That behavior is also responsible for 
handling keyboard and other types of events for navigation on the
list, e.g. it sets :current state flag for the current item, etc.
That is also trivial I think.

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Saturday, 29 March 2008 04:30:12 GMT

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