Quoting Lachlan Hunt <lachlan.hunt at lachy.id.au>:
>>> My point is that this command menu is basically made up of a label,
>>> a select control and a button, and that we already have a <label>
>>> element for associating with select elements. Therefore, we don't
>>> need to use another type of label element for that. <menulabel> is
>>> fine for navigational menus.
>>
>> That would also require a <form> element around the command menu.
>
> Is there a problem with that? My initial suggestion in this thread
> included the form element, subsequent discussion assumed it would be
> present in the surrounding document.
Fair enough. I just don't see the thing as it is used in Gmail for
example as a
form. More as a standalone widget separate from the form.
>> I wonder if there always is a <form> element. There was also this
>> suggestion:
>>
>> # <select>
>> # <option label>Action ...
>> # <option>Select All
>> # <option>Deselect All
>> # <option>Archive Selected
>> # </select>
>
> That's an interesting idea, and kind of fits with the existing abuse of
> the first option as a label, rather than an actual option, as in:
>
> <select>
> <option>Please Select
> <option>foo
> </select>
>
>> Now assuming scripting is more or less required for applications
>
> Why should script be required for applications?
I believe this was one of the baselines once mentioned here on this
list by Ian.
I kind of agree with that. Making everything fallback is just not going
to work.
And accessibility clients can just build on top of the DOM (what they
should do
anyway).
> I believe there should
> be fallback for users with JS disabled, unsupported or even in older UAs
> which may have script enabled, but for some reason, the script might be
> broken for them.
We are talking about applications here. I think you can assume JS should be
enabled and I don't think they should work in Netscape 4 either or some other
browser that is no longer in use.
> (eg. existing UAs don't support the new DOM methods
> introduced in this spec, and if the author doesn't handle such
> conditions, then it's effectively another UA without script support.
Well yeah, but that is always the case. If you use 'application/xhtml+xml' as
media type for your site you're also excluding people from using your site.
>> Perhaps put some additional container element around it and make <select>
>> optional for fallback (same as with <datalist>) and you have some kind of
>> solution.
>
> Do you mean like this:
>
> <cmd>
> <option>foo
> <option>bar
> </cmd>
>
> would be the same as:
>
> <cmd>
> <select>
> <option>foo
> <option>bar
> </select>
> <button/>
> </cmd>
>
> Since the first would only be supported by new UAs with no good
> fallback, the button would be completely unnecessary.
Yeah, I meant that. And I like it now I see it :-)
--
Anne van Kesteren
<http://annevankesteren.nl/>