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

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

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

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

or

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

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

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs

Received on Wednesday, 8 June 2005 02:49:02 UTC