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

>  * how to draw the tree lines/twisties.  There are a bunch of
>    different cases:
>    Twisties for:
>     * tree nodes without children

Regular list markers affect line height, but these wont.
So, how big a vertical space does an empty tree node leave ?

Also, how do you draw these tree lines / twisties when text direction
changes ?
<ul>
<li style="direction:rtl;"> </li>
<li style="direction:ltr;"> </li>
</ul>

These are just details, that must be worked out and must make its way into
the spec.

Sushanth.


>
>
> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Andrew Fedoniouk
> Sent: Friday, March 28, 2008 9:32 PM
> To: dbaron@dbaron.org; www-style
> Subject: Re: [CSS3] Proposal to add list-style-type: tree-line value
>
>
> 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 Thursday, 3 April 2008 01:07:41 UTC