- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Wed, 12 Sep 2007 16:28:36 +0300
- To: public-html <public-html@w3.org>
Hello! 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. 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 correct. 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 type=checkbox|radio? 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 elements. 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). 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 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. That's about all, for now. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#the-command [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#hidden [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-global.html#the-irrelevant [4] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#menus [5] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#autosubmit [6] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#context [7] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#commands [8] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#using -- http://www.robodesign.ro
Received on Wednesday, 12 September 2007 13:28:50 UTC