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

[Matthew Raymond]

James Graham wrote:
> Matthew Raymond wrote:
> 
> 
>>J. Graham wrote:
>>
>>
>>>On Tue, 7 Jun 2005, Matthew Raymond wrote:
>>
>>[Snip!]
>>
>>
>>>>| <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>
>>>
>>   (Above example left for other readers to reference.)
>>
>>
>>>> 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?
>>
>>
>>   Well, you use the |class| attribute for styling purposes. 
>>Therefore, assuming selection is semantic (and I feel it is, since 
>>it's already used by <select> and such), then the <selectgroup> 
>>element is effectively styling members of a class with new semantics 
>>they otherwise wouldn't have.
> 
> 
> Well yes, sort of. But I don't see that as being incompatible with the 
> way that class is supposed to be used. The HTML 4 spec is less than 
> entirely clear but it does say class can be used "for general purpose 
> processing by user agents".

    I don't think that new markup to assign semantics via classes is 
what they meant by that. They're talking about allowing user agents to 
assign additional semantics to predefined class names. You're talking 
about creating the first element in a sublanguage of HTML to perform 
semantic styling.

 > This seems to be an example to general
> purpose processing - class groups the elements and we attach  behavior 
> to a particular group. It's certianly much less of a crime than anything 
> that may appear under http://whatwg.org/specs/web-apps/current-work/#classes

    There's not much there right now, but it seems the spec will allow 
user agents to use predefined class names in a predefined namespace (via 
|profile|) for special processing. In every case, the profiles and 
classes are predefined and hardcoded into the user agent.

>>   Why would we need Javascript for selection? My examples with <sl> 
>>and <switch> didn't use Javascript at all. (Of course, my examples 
>>assumed that clicking on a link to a <section> inside <switch> would 
>>make that <section> active, which isn't in the spec, as far as I know.)
> 
> My point is, if there's no way to interact with the selection except via 
> script, it makes no sense to provide anything other than script-based 
> interfaces to it.

    Er...but I have no intention of making selection only accessible via 
script. My system defines the selection type ("single", "multiple", et 
cetera) and what can be selected in markup, then allows the user to 
change the selection directly without the use of Javascript.

 > Unless there are actual declarative things to do with
> the selection in the spec (such as your suggestion), I'm very much 
> opposed to having _any_markup for this problem.

    So would I, because then you could just use Javascript to assign a 
"selected" class and style the class.

>>>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?
>>
>>   Selection is clearly not presentational. You might call it 
>>behavioral, but it's definitely not presentational, because a 
>>selection in a form control can be submitted. Therefore, selection 
>>should NEVER be defined in CSS.
> 
> Sure. This is why I'm wondering how sXBL deals with binding to elements. 
> Imagining that the <table> in the example had id="tableid" One could do 
> something like:
> <selectgroup multiple="False" bind="table#tableid td" />

    Actually, I think you could probably use XBL to apply my system to 
elements via CSS binding. Having selectors in HTML seems kinda scary to 
me...

> or
> 
> <bindings>
> table#tableid td {
>   select:multiple;
> }
> </bindings>

    You can bind CSS using sXBL/XBL2???

> or similar things with XPath. But I'm ad-libing here and am becoming 
> increasingly worried that the whole thing looks like XForms.

    Actually, the whole thing looks like an HTML version of semantic CSS 
properties.

    I'd like to note that there is a lot of potential abuse with the 
<selectgroup> element. Here's an example:

| <selectgroup multiple="false" bind="table#tableid td" />
| <selectgroup multiple="true" bind="myclass1" />
| <selectgroup multiple="true" bind="myclass2" />
|
| <table id="tableid">
|   <tr>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td class="myclass"> ...contents... </td>
|   </tr>
|   <tr>
|     <td class="myclass"> ...contents... </td>
|   </tr>
| </table>
|
| <p>
|   There's nothing as useless as a lock with a
|   <span class="myclass1">voice print</span>.
| </p>
|
| <ul>
|   <li class="myclass1">Item 1</li>
|   <li class="myclass2">Item 2</li>
|   <li class="myclass2">Item 3</li>
| </ul>

    Note that such abuses aren't possible in my system:

| <table selection="single">
|   <tr>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td> ...contents... </td>
|   </tr>
| </table>
|
| <p>
|   There's nothing as useless as a lock with a
|   <span class="myclass1">voice print</span>.
| </p>
|
| <ul selection="multiple">
|   <li>Item 1</li>
|   <li>Item 2</li>
|   <li>Item 3</li>
| </ul>

    One thing I do notice, though, is that your system is more flexible 
in that it allows grandchildren or more deeply nested nodes to be 
selectable rather than immediate children. Such things are possible in 
my system, but it's not as elegant:

| <table selection="single tree">
|   <tbody unselectable>
|     <tr selection="single">
|       <td>Item1</td>
|       <td unselectable> ...contents... </td>
|       <td unselectable> ...contents... </td>
|     </tr>
|     <tr selection="single">
|       <td>Item1</td>
|       <td unselectable> ...contents... </td>
|       <td unselectable> ...contents... </td>
|     </tr>
|     <tr selection="single">
|       <td>Item1</td>
|       <td unselectable> ...contents... </td>
|       <td unselectable> ...contents... </td>
|     </tr>
|   </tbody>
| </table>

    Of course, what we could do is allow for implicit and explicit 
selectability in such a way that grandchildren, et cetera, could be 
selected.

| <table selection="single explicit">
|   <tr>
|     <td selectable="true">Item 1</td>
|     <td> ...contents... </td>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td selectable="true">Item 2</td>
|     <td> ...contents... </td>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td selectable="true">Item 3</td>
|     <td> ...contents... </td>
|     <td> ...contents... </td>
|   </tr>
| </table>

    This approach changes "unselectable" to an attribute |selectable| 
with a true or false value. If the |selection| attribute of the ancestor 
  has the word "explicit" in it, |selectable| defaults to "false", 
otherwise it defaults to "true".

    Hmm. There's probably a better term than "explicit". Perhaps 
something like this:

| <table selection="single" select-default="false">
|   <tr>
|     <td selectable="true">Item 1</td>
|     <td> ...contents... </td>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td selectable="true">Item 2</td>
|     <td> ...contents... </td>
|     <td> ...contents... </td>
|   </tr>
|   <tr>
|     <td selectable="true">Item 3</td>
|     <td> ...contents... </td>
|     <td> ...contents... </td>
|   </tr>
| </table>

    Any descendant of <table> would be selectable if its |selectable| 
attribute is "true", unless that descendant has a selectable parent. The 
|select-default| attribute defines what the default is for |selectable|, 
ant the default for |select-default| is "true".

    Trees would work like this:

| <ul selection="multiple tree" select-default="false">
|   <li>Item 1
|     <ul selection="multiple">
|       <li>Item 1</li>
|       <li>Item 2</li>
|       <li>Item 3</li>
|     </ul>
|   </li>
|   <li selectable="true">Item 2</li>
|   <li selectable="true">Item 3</li>
| </ul>

    Yeah, I'm liking these new revisions...