[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
lachlan.hunt at lachy.id.au
Fri Dec 2 06:01:55 PST 2005
Anne van Kesteren wrote:
> 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.
> 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:
> Now assuming scripting is more or less required for applications
Why should script be required for applications? 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. (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.
> Perhaps put some additional container element around it and make <select>
> optional for fallback (same as with <datalist>) and you have some kind of
Do you mean like this:
would be the same as:
Since the first would only be supported by new UAs with no good
fallback, the button would be completely unnecessary.
More information about the whatwg