[whatwg] [WA1] <sl> - The Selection List element

[Matthew Raymond]

James Graham wrote:
> Aankhen wrote:
> 
>>>Reusing class has the added
>>>advantage that authors are already familar with grouping items through
>>>the class attribute and in particular, are already familar with
>>>attaching style through class. This should make for a shallow learning
>>>curve as using new features will be a simple matter of reusing existing
>>>markup habits.
>>
>>I understand why it is preferable.  I'm just a little wary of
>>attaching semantics to specific classes, since they could conceivably
>>collide with user classes.  One possible solution is to make them as
>>long as possible, so that the likelihood is much lower; however, that
>>reduces their usefulness, IMHO.
> 
> I totally agree. I'm not really suggesting attching semantics to
> particular class names (although others are, in other places - the needs
> some simple form of namespacing imho). I'm more suggesting that we have
> a mechanism to attach predefined behaviors (such as selection) based on
> class name. So I guess we could have an element like <selectgroup
> classname="myclass" multiple="False" /> or somesuch to attach a behavior
> to all the elements in class "myclass".

     I presume you're referring to something like this:

| <selectgroup classname="myclass1" multiple="False" />
|
| <table>
|   <tbody>
|     <tr>
|       [...header row...]
|     </tr>
|     <tr class="myclass1">
|       [...first row of block two data...]
|     </tr>
|     <tr class="myclass1">
|       [...second row of block two data...]
|     </tr>
|     <tr class="myclass1">
|       [...third row of block two data...]
|     </tr>
|   </tbody>
| </table>

    This seems like a good way to handle it at first, but there are 
several problems, not the least of which is the fact that you're 
creating a new element that amounts to a semantic styling tag. Another 
problem is that this can cause serious problems if someone forgets to 
put the class name inside a template, thus making all items created by a 
user unselectable. Or you could have situations where simple 
misspellings make things unselectable.

    Now suppose we let the templating system work for us...

| <table>
|   <tbody>
|     <tr>
|       [...header row...]
|     </tr>
|     <tr repeat="1" selected="selected">
|       [...first row of block two data...]
|     </tr>
|     <tr repeat="2">
|       [...second row of block two data...]
|     </tr>
|     <tr repeat="template" repeat-selection="single">
|       [...third row of block two data...]
|     </tr>
|   </tbody>
| </table>

    In this manner, we not only make all blocks associated with a 
template selectable, but we also define the type of selection, and all 
without adding new elements or forcing the author to create new classes.

    The downside of this is that we're forced to use templates for 
selection. One solution is to create a property that applies to a parent 
element that makes all of the immediate children selectable:

| <ul selection="single">
|   <il selected="selected">Item 1</il>
|   <il>Item 2</il>
|   <il>Item 3</il>
| </ul>

    In the case of tables, it might look like this:

| <table>
|   <tbody>
|     <tr>
|       [...header row...]
|     </tr>
|   </tbody>
|   <tbody selection="single">
|     <tr selected="selected">
|       [...first row of block two data...]
|     </tr>
|     <tr>
|       [...second row of block two data...]
|     </tr>
|     <tr>
|       [...third row of block two data...]
|     </tr>
|   </tbody>
| </table>

    Or in HTML:
| <table>
|   <tbody>
|     <tr> [...header row...]
|   <tbody selection="single">
|     <tr selected> [...first row of block two data...]
|     <tr> [...second row of block two data...]
|     <tr> [...third row of block two data...]
| </table>

    Of course, this still leaves cases where you want certain children 
to be unselectable -- oh, wait -- "unselectable"!!!

| <table>
|   <tbody selection="single">
|     <tr unselectable> [...header row...]
|     <tr selected> [...first row of block two data...]
|     <tr> [...second row of block two data...]
|     <tr> [...third row of block two data...]
| </table>

    Perhaps in cases where <tbody> and the gang aren't specified, the 
properties could be passed straight to the implied <tbody>:

| <table selection="single">
|   <tr unselectable> [...header row...]
|   <tr selected> [...first row of block two data...]
|   <tr> [...second row of block two data...]
|   <tr> [...third row of block two data...]
| </table>

    Of course, this doesn't necessarily support selection in a tree-like 
structure, but it could probably be extended to support it:

| <ul selection="multiple tree">
|   <il unselectable>Item 1
|     <ul selection="multiple">
|       <il selected>Item 1a</il>
|       <il>Item 1b</il>
|       <il>Item 1c</il>
|     </ul>
|   </il>
|   <il>Item 2</il>
|   <il>Item 3</il>
| </ul>

    Any thoughts on all of this?