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

[J. Graham]

On Tue, 7 Jun 2005, Matthew Raymond wrote:

>    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>

Yes.

>
>   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.

Eh? What's a semantic styling tag? What I'm saying is that, if we want 
things like selection to work declaratively, one possibility is to use an 
element to bind certian classes to a behavior. There are, of course, other 
possibilities - is a declarative solution even necessary? What could a UA 
do with selection (or drag/drop) information if js is turned off? Could 
one use a CSS/mozilla-XBL like solution instead (i.e.
.myclass {select:multiple;} ) - maybe not if we consider this to be 
'semantic' - but what does sXBL (or whatever it's called now) do?


> 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.

Well, er, yes. In the same way that a  misspelling in any piece of 
javascript can prevent that code working, a misspelling in a class 
attribute can prevent the expected style selectors matching an element... 
These things are typically solved by testing. Why is this suggestion any 
harder to test than any other part of the language?