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

Re: Collapsing elements

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 21 Feb 2008 12:11:17 -0800
Message-ID: <47BDDAE5.1010708@terrainformatica.com>
To: Alan Gresley <alan1@azzurum.com>
CC: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style <www-style@w3.org>, Bert Bos <bert@w3.org>

Alan Gresley wrote:
> Daniel Glazman wrote:
>
>   
>> Bert Bos wrote:
>>
>>
>>     
>>> Another example:
>>>
>>>     div:initial * {display: none}
>>>     div:initial h2 {display: block}
>>>
>>>     ...
>>>     <div>
>>>       <h2>Heading of this section</h2>
>>>       <p>First paragraph...
>>>       ...
>>>     </div>
>>>       
>> Right, that works for LI and sub-lists. But how do you
>> query from JS the state of such a list item, expanded or
>> collapsed ? Checking the computed value of the display
>> property on all children of that LI is not a workable
>> solution.
>>
>> We need to be able to query 'something' directly from the LI.
>> That means a solution based uniquely on the display property
>> of the children is not enough. We need an attribute on the LI
>> or a unique CSS property setting the expanded/folded status
>> of the item.
>>
>> </Daniel>
>>     
>
>
> Do we have to query the list itself in all cases. Maybe not with the same functionality but all we need to do is be able to navigate to hidden list items in nested list menus. The + and - icons in Andrew Fedoniouk's [1] screenshot are selectable objects which are open by a left click or ENTER. Something like Window Explorers. Using anchor bookmarks, a bit of CSS (:focus) and a very good UA implementation this can somewhat done already using this markup.
>
>
> <ul>
> <li><a>(-)`Metals</a><ul>
>                <li><a>(-) Alkaline Metals</a><ul>
>                                <li>Lithium</li>
>                                <li>Sodium</li>
>                                <li>Potassium</li></ul></li>
>                <li><a>(+) Transition Metals</a></li>
> </ul>
>
>   
Alan, about those [+] and [-] signs...

I do have such thing as foreground-image[1] with the bunch of other 
foreground-*** attributes
that mimic exactly correspondent background-image related attributes.
These [+] and [-] are defined as such foreground image for the <options> 
element.

In my case markup I have looks like:

<options>
      <caption>Alkaline Metals<caption>
      <option>Lithium</option>
      <option>Sodium</option>
      <option>Potassium</option>
</options>

is styled as:

options
{
   foreground-repeat: no-repeat;
   position: x y;
}

options:expanded
{
    foreground-image: url(minus.img);
}
options:collapsed
{
    foreground-image: url(plus.img);
}
 
Case when foreground image is declared as:
{
  foreground-image: url(...);
  foreground-repeat: no-repeat;
}
is treated specially in the engine - such an image is considered as an 
"icon" of the element.
All mouse events have special flag: MouseEvent.isOnIcon.
This flag allows to handle events on icon specifically - change cursor and
handle "click-on-icon" cases.

I really think that foreground-*** feature is a good thing.

Speaking about key handling and CSS.

I think that it really makes sense to add set of typical "behaviors" to CSS.

I propose to reuse "behavior" attribute for that. Such extended behavior 
attribute
may accept list of predefined values:

behavior: select | multi-select | radio | checkbox | tab-switch | ...;

Behaviors here are named built-in entities (event handlers) that are 
implemented
in UA code natively.  Functionality of each behavior can be 
defined/specified in
the BECSS document as set of statements (finite state automata definition):
     action key press "left" -> triggers :collapse of :current element, etc.
    
For example declaration:

ul.tree { behavior:select; ... }

will assign select behavior to all ul.tree elements so they will accept 
focus and
react on keys up,down,left, right etc.

List of all popular behaviors used in modern Web UI is surprisingly short.
Having them will allow to minimize need of scripting at the great extent.

Behavior as an entity is a set of event handlers that handle UI events
and change state of DOM elements. Author just need to style them on 
his/her own taste.

--
Andrew Fedoniouk.

http://terrainformatica.com





















 
Received on Thursday, 21 February 2008 20:11:41 GMT

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