- From: Brad Kemper <brkemper@comcast.net>
- Date: Sat, 1 Mar 2008 09:17:06 -0800
- To: Bert Bos <bert@w3.org>, Andrew Fedoniouk <news@terrainformatica.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, Alan Gresley <alan1@azzurum.com>
- Cc: www-style list <www-style@w3.org>
- Message-Id: <6F830802-DF86-4B83-8375-6247EA07489D@comcast.net>
I don't want to diminish the usefulness of being able to create a tree-like list simply by setting the list-style-type (or being able to style the "::marker" to set color, width, line-width, dotted, etc. of the line), nor of being able to set presentational behaviors (such as checkbox-like behavior) to any element. I do believe that checkbox- like behavior is what is needed in order to change between states for a collapsable list, just as radio-button-like behavior is what is needed in order to change between states of a tabs panel. To illustrate this point, I've created a working collapsable tree list that uses already implemented features of CSS3. Instead of using a list-style-type, it has generated content to create a small, absolutely-positioned block to the left of each LI, and this small block has two border edges. Each LI also has a left border edge that the small box aligns with. For the collapsing/expanding behavior, each UL is inside an LI, and preceded by a checkbox and label. The ":checked" pseudo-class is used with adjacency selectors and the label to set the display of the UL when the user clicks on the label (or when the author sets the "checked" attribute in the HTML). You can see it here, with explanatory notes: http://bradclicks.com/cssplay/foldingList.html Because of the CSS3, it has varied success depending on the browser you use. FireFox 3 works well (except I had to use a CSS hack to work around the fact that it would not absolutely position the generated content). The shipping version of Opera works well (except that it doesn't understand "last-child", so the lines on the tree-list do not look right). And Safari 3 looks good and handles the selectors correctly (but only with the initial author-set settings: it does not change when the user clicks to change the state of the checkbox). On Feb 21, 2008, at 12:45 AM, Brad Kemper wrote: > > On Feb 20, 2008, at 3:16 PM, Bert Bos wrote: > >> Daniel Glazman wrote: >>> Andrew Fedoniouk wrote: >>>> >>>> I think it makes sense to add another value to the list-style- >>>> type enumeration - "tree-line". >>> Wow, that's far more than stylistic Andrew... That's clearly >>> behavioural. But that is only a part of the solution needed for >>> UL/LI turned into foldable trees. We need a queryable way to >>> specify an >>> item is folded or not too... Right ? >> >> Actually, I think I like it... > > Me too. > >> >> It's a very easy way to get a tree-like list display. I can do >> without detailed control over the look of the lines. >> > > > I would prefer to have control over the lines. At the very least, > the color of the lines. They could appear in front of any > background, light or dark, so color would be very helpful, but why > not thickness and style (dotted, etc.) too, following the syntax of > border and outline? It would help in making it fit in with its > surrounding design. > > You could do away with a new type of line, though, if the lines > were considered a special kind of markers of lists, and if > the ::marker pseudo-element [1] is adopted, and the "tree-line" > became a standard marker glyph type that was always connected to > the one above it of the same level (like a transparent rectangle > with two edges that would accept outlines, and an intrinsic > height). Then you could have something like this: > > LI { color: black; list-style-type: tree; } > LI::marker { color: powderblue; outline-style:dotted; outline-width: > 1px; } > > I chose outline over border, because I think it would make it > easier to align. > > If you wanted a OS UI tree view, with the (not necessarily > functional) widgets for expanding/collapsing, you should be able to > do something like this: > > ul { appearance: outline-tree; } > > The widgets (plus and minus signs in boxes, for instance) could be > PNGs with system defaults when using the system appearance. Then > the image could be changed with something like this: > > LI::marker { > color: powderblue; > outline-style:dotted; > outline-width:1px; > content: url(plusbox.png); > } > LI::marker:hover { > content: url(plusbox-over.png); > } > LI::marker:active { > content: url(plusbox-pressed.png); > } > LI:checked::marker { > content: url(minusbox.png); > } > LI:checked::marker:hover { > content: url(minusbox-over.png); > } > LI:checked::marker:active { > content: url(minusbox-pressed.png); > } > > I am imagining the "checked" pseudo-class [2] would represent the > "on" state of an expanded item. > > > [1] http://www.w3.org/TR/2002/WD-css3-lists-20021107/#markers > [2] http://www.w3.org/TR/css3-selectors/#UIstates
Received on Saturday, 1 March 2008 17:17:39 UTC