[whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[Anne van Kesteren]

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