Re: Detailed review of 3.18.3. The command and 3.18.4. the menu elements

On Wed, 12 Sep 2007, Mihai Sucan wrote:
> 
> I have reviewed section 3.18.3. "The command element" [1]. I have the 
> following comments to make:
> 
> 1. The attribute named "hidden" [2] is defined for the command element 
> like this:
> 
> "The hidden attribute is a boolean attribute that, if present, indicates 
> that the command is not relevant and is to be hidden."
> 
> That means, one should use "hidden" for irrelevant commands, depending 
> on the context, as further explained by the spec.
> 
> Now, here's the definition of the common attribute named "irrelevant", 
> defined somewhere else in the spec [3]:
> 
> "All elements may have the irrelevant content attribute set. The 
> irrelevant attribute is a boolean attribute. When specified on an 
> element, it indicates that the element is not yet, or is no longer, 
> relevant. User agents should not render elements that have the 
> irrelevant attribute specified."
> 
> I believe there's an almost complete overlapping between the two 
> attributes. The common attribute "irrelevant" has a better name, in my 
> opinion (it's not a presentational attribute - at least based on the 
> name).
> 
> I would suggest removing this duplication: remove the "hidden" 
> attribute. However, make sure you remind authors and implementors about 
> the "irrelevant" attribute.
> 
> If both attributes remain I wonder if there's any use-case for having 
> both attributes set to true? Why would anyone use hidden *and* 
> irrelevant? Both do the same.

I've merged them both into one global attribute hidden="".


> 2. "Big Issue: should change all the above so it actually is just 
> trigged by a click event, then we could remove the shadowing click() 
> method and rely on actual events."
> 
> Yes, that should be done.

Noted.

> I do not agree with the current spec definition of the click() method. I 
> want to be able to fire a synthetic click event at the element, and have 
> it work like the click() method does. There's absolutely no reason to 
> overly complicate things.
>
> Make the defined "algorithm" to be triggered by the click event.

Actually making things happen based on event listeners instead of as 
default actions is pretty complicated. The way the spec does it ends up 
being simpler.


> 3. I don't think having commands where metadata elements are expected is 
> correct.
> 
> Commands are not metadata elements.

They will be, once we allow them to be used anywhere and then referred to 
using command="".


> 2. I'd like to better understand the autosubmit attribute [5], defined 
> for the menu element.

It's gone.


> 3. In the section 3.18.4.3. "Context menus" [6] I cannot find any 
> mention about this scenario:
> 
> <menu id="myMenu">
> <command ...>...</command>
> <command contextmenu="myMenu2" ...>...</command>
> <command ...>...</command>
> </menu>
> 
> <menu id="myMenu2">
> ...
> </menu>
> 
> <p contextmenu="myMenu">Right-click this!</p>
> 
> This scenario "nests" context menus. For now, I don't know any software 
> application which allows to right-click on a context menu for a "second 
> level" context menu, but that's not impossible.
> 
> Should the spec disallow the usage of the contextmenu attribute within 
> context menus?
> 
> Also, how about this:
> 
> <menu id="myMenu" contextmenu="myMenu">
> ...
> </menu>
> 
> or ...
> 
> <menu id="myMenu">
> <command ...>...</command>
> <command contextmenu="myMenu" ...>...</command>
> <command ...>...</command>
> </menu>
> 
> How should UAs deal with these cases?
>
> I think the contextmenu attribute should be disallowed for several 
> elements (at least menu and command), and disallowed on any element 
> found within menus which are used as context menus (quite hard).

There's no reason this shouldn't actually work (same with drag and drop of 
elements in menus, I guess). It's just a bit... exotic.


> In the section 3.18.5.1. "Using the a element to define a command" [8] 
> one can read:
> 
> "The Hidden State and Disabled State facets of the command are always 
> false. (The command is always enabled.)"
> 
> Why can't the Hidden State be true for anchors? <a irrelevant>
> 
> The Hidden State should be based on the "irrelevant" attribute in all 
> cases - better unification of the spec.
> 
> Anchors, inputs, options, buttons can all be irrelevant, thus can have 
> the Hidden State set to true.

Done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 28 August 2008 11:23:05 UTC