W3C home > Mailing lists > Public > public-html@w3.org > September 2007

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

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Wed, 12 Sep 2007 16:28:36 +0300
To: public-html <public-html@w3.org>
Message-ID: <op.tyjmdycomcpsjgr0b0dp@athlon>


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  

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.

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.

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.

3. I don't think having commands where metadata elements are expected is  

Commands are not metadata elements.

Immediately following is the menu element definition, section 3.18.4 [4].

1. In the definition of the menu element, second paragraph, fourth phrase:

"The toolbar keyword maps to the tool bar state, in which the element is  
*declaraing* a tool bar."

The emphasized word has a typo: declaraing. That should be "declaring".

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

Why was it defined? What are the use-cases for having a menu which  
automatically submits the form when the user changes input  

I can't put into doubt the addition of the attribute - it's definitely  
there for a reason. I'm just curious what's the idea behind it?

Why have the autosubmit attribute on menu elements, instead of, say, form  
elements? I would find the autosubmit attribute more appropriate for form  

3. In the section "Context menus" [6] I cannot find any mention  
about this scenario:

<menu id="myMenu">
<command ...>...</command>
<command contextmenu="myMenu2" ...>...</command>
<command ...>...</command>

<menu id="myMenu2">

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

or ...

<menu id="myMenu">
<command ...>...</command>
<command contextmenu="myMenu" ...>...</command>
<command ...>...</command>

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).

The following section 3.18.5. "Commands" [7]:

1. While I like the general concept of commands, I can't help to point out  
the duplication of the "irrelevant" attribute [3].

In the section "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.

That's about all, for now.


Received on Wednesday, 12 September 2007 13:28:50 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:21 UTC