On Mon, 28 Nov 2005, Lachlan Hunt wrote: > > > 4. Replacing ad-hoc DHTML context menus with something more accessible, > > that doesn't necessarily replace the UA's own context menus. > > If the spec were to address this kind of menu, then it must not > completely override the UAs own context menu. However, since these > aren't really discoverable until the user right clicks to do something, > only to discover their expected menu has been replaced (or at least > modified) it may be more of an annoyance than a useful feature. Of > course, that doesn't stop authors attempting them already using JS.
Right; one of the major advantages of doing this semantically is that the UA can merge the author's context menu with the UA's. > I disagree, I see use cases 2 and 3 as completely separate (as described > above), not just variations of each other. Sure, they have different semantics. But they are still menus. They would have different ideal markup, and different non-JS fallback (e.g. <a> vs <button> as the tags describing the commands) but they're still menus. > > Matthew has pretty much convinced me that trying to grandfather the > > current DHTML menu syntaxes into the new markup is not worth it, so we > > can ignore that requirement. > > Could you please explain what "grandfather the current DHTML menu > syntaxes into the new markup" means or references to a few of Matthew's > specific posts describing the issue? See, e.g., http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-November/002411.html http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-October/004890.html ...and other posts on those threads. > How about this, or some variation of: > > <form ...> > <menubar> > <li><button type="submit" for="foo" name="menu">Foo</button> > <select id="foo" name="foo"> > ... > </select> > </li> > <li><button type="submit" for="bar" name="menu">Bar</button> > <select id="bar" name="bar"> > ... > </select> > </li> > </menubar> > </form> > > -- Behaviour in Current UAs -- > > * User selects item from select menu, button submits it. > * Con: Submit button occurs before form control, though they typically occur > after, which may be bad for usability in current/older UAs (could be changed > with CSS, I guess). > * Very good support for UAs without JS (assuming the server side processing > has been implemented to support it) Interesting idea. I like the non-JS fallback potential. Pity about the <menubar> being necessary to get the <select> to disappear, but I guess we need that... It's unfortunate about the button being first, too. I guess we could change that if we say that in the new world in an <li> any <select>s are ignored and just the <button> is looked for... Hmm. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'