- From: Brad Kemper <brkemper@comcast.net>
- Date: Sun, 2 Mar 2008 12:20:36 -0800
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: Bert Bos <bert@w3.org>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, Alan Gresley <alan1@azzurum.com>, www-style list <www-style@w3.org>
On Mar 1, 2008, at 12:15 PM, Andrew Fedoniouk wrote: > Solution with adjacent sibling combinator: > > input + label + ul { display:none; } > input:checked + label + ul { display:block; } > > looks very interesting and cool but it is not always possible > to put trigger element (checkbox here) near (in terms of DOM position) > the collapsible target. Think about tabs/stacked elements > implementation where tabs bar is pretty far in the DOM from > list of panels it is aimed to switch. Personally, I think it is pretty natural to have the content for each tab adjacent to its label, at least at the HTML code level. That is how I set it up in my other demo example for tabs [1]. But I was also thinking about how something like "move-to" would be useful there also.[2] It would allow you to have the content together with the label in the HTML, and then move the content to some other box using CSS. You could even use it to move the tabs to the bottom of the box, if you wanted. I'm not a huge fan of the syntax of "move-to" (I'd rather it just used existing ID attributes in the HTML, the way innerHTML does, rather than create its own system of identifiers), but I like what it allows you to do, and it seems like a simpler way to deal with translating my demo into something that addresses your concern (once "move-to" or whatever it evolves to is supported). Of course, if checkbox-like behavior could be assigned to any element, then adjacent sibling combinators are not needed. > One of early ideas was to define @bound-target and @bound-state > attributes. > > Having them your sample could use: > > input > { > bound-target: selector( :this + label + ul ); > bound-state: :collapsed; > } > input:checked > { > bound-state: :expanded; > } One thing I dislike about using the words "expanded" or "collapsed" as pseudo-classes is that they really just seem to describe the visual styling (achievable using "display" or "visibility" or "height/ overflow", etc.) of an "on/off" type of state. I'd much rather the binary state remain an abstract notion with arbitrary meaning, as it currently is with checkboxes, and use whatever styling you choose to represent those two states. You could even create something like Outlook's 2-line message preview by setting the height of the un- checked state to be equal to the line-height times 2 (and a fuller preview for the "checked" state would be "height:auto; overflow:auto" and moved over with absolute positioning into a preview area). > And some abstract tabbed stack can be defined as: > > input[type=radio].tab > { > bound-target: selector( div.panel:nth-child( @this.index ) ); > bound-state: :collapsed; > } > input[type=radio].tab:checked > { > bound-state: :expanded; > } > > As you may see I am forced to use some funny things like > @this.index that is position in the DOM of the element > this css attribute is applied to. But if you will go in > this direction you will end up with the need of creation > of full programming language. Yes, I'd rather keep it simpler than that. That seems like overkill, just to be able to handle having the tab content separated from the tab label, something that "move-to" would be able to handle when needed. > > And yet bound-target/bound-state are not solving problems of > event handling. In case of tree view that we discuss here > it should be focusable element that support navigation and > collapsing/expanding by keyboard. I was thinking that labels were focusable and activate-able via keyboard, but that might not be universal. It might mean that for my example I would need to keep the actual checkboxes displayed but clipped if I didn't want them visible, and use some appearance-styled outline on the label when the ckeckbox is checked. Of course, if I could assign checkbox behavior directly to the LI, then that should also include the keyboard activation that checkboxes currently enjoy (using "spacebar", on the Mac, when full keyboard access to all controls is turned on in the "Keyboard & Mouse" system preference). > Think about > up/down/left/right keyboard keys handling for example. Having different keyboard access than what is used for checkboxes might make sense if the meaning of "collapsed" and "expanded" was significantly distinct (beyond the purely visual) from unchecked and "checked", enough too warrant different attributes and selectors. Are they? Would that have more meaning to a screen reader, for instance, causing it to intentionally skip over collapsed elements that it otherwise wouldn't? If so, would arrow keys be better than the activation key that works on other elements, such as the various forms elements? If there is no semantic (non-visual) difference between "collapsed / expanded" and "[default] / checked", or if the screen reader software could never be expected to catch up to modern times or to do the right thing, then I'd just stick with "checked" to represent the alternate state. > > -- > Andrew Fedoniouk. > > http://terrainformatica.com > [1] http://bradclicks.com/cssplay/tabs.html [2] http://www.w3.org/TR/2003/WD-css3-content-20030514/#moving
Received on Sunday, 2 March 2008 20:20:58 UTC