Quoting Lachlan Hunt <[EMAIL PROTECTED]>:
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/>
