W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 12949] click() shouldn't have special powers over dispatching click event manually

From: <bugzilla@jessica.w3.org>
Date: Sun, 03 Jul 2011 09:37:20 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QdJ7A-0006eQ-7r@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12949

--- Comment #15 from Jan Varga <jan.varga@gmail.com> 2011-07-03 09:37:17 UTC ---
(In reply to comment #6)
> So the way activation behavior is defined in HTML is just wrong - 
> well at least it doesn't reflect the reality.
> Or I'm reading the spec wrong.
> Anyway, click() doesn't work differently to dispatching click manually.
> 
> There can be differences in default handling, but that is a separate thing.
> 
> In Gecko, and I think in Webkit too, and based on the testcase also
> other browsers there is
> 1. event target chain creation
> 2. pre-handle-event phase
> 3. actual dom event dispatch
> 4. post-handle-event phase, including default handling

I think that pre-handle-event phase corresponds to "pre-click activation
steps".
post-handle-event-phase runs "post-click activation steps" or "canceled
activation steps" (at least for nsHTMLInputElement)

http://www.w3.org/TR/DOM-Level-3-Events/ - 3.5 Activation triggers and
behavior) says it's up to host language to indicate which elements have
activation behavior.

http://www.whatwg.org/specs/web-apps/current-work/ - 4.10.7.1.16 Checkbox state
"If the element is mutable, then: The pre-click activation steps consist of
setting the element's checkedness to its opposite value (i.e. true if it is
false, false if it is true), and of setting the element's indeterminate IDL
attribute to false. The canceled activation steps consist of setting the
checkedness and the element's indeterminate IDL attribute back to the values
they had before the pre-click activation steps were run. The activation
behavior is to fire a simple event that bubbles named change at the element."

that's exactly what nsHTMLInputElement does

however, the HTML5 spec adds command definitions and "enhance" element.click()
in a way, I found out that there use to be a Command IDL interface:

interface Command {
  readonly attribute DOMString commandType;          
  readonly attribute DOMString id;
  readonly attribute DOMString label;
  readonly attribute DOMString title;
  readonly attribute DOMString icon;
  readonly attribute boolean hidden;
  readonly attribute boolean disabled;              
  readonly attribute boolean checked;              
  void click();
  readonly attribute HTMLCollection triggers;
  readonly attribute Command command;
};

you can find more details in the first (SVN) revision of the spec

at that time only <a>, <button>, <input>, <option> and <command> could define a
command and command.click() was defined to trigger the action for the command

however, after some time (several years), accesskey="" was added as another
possibility to define a command
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019579.html
so now any element can define a command and it is quite logical to merge the
Command and HTMLElement IDL interface.

so element.click() got these "special" powers ... to trigger the action for the
command

Now when I look at the definition of "Action" in
http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#concept-command

4.11.5.1 <a href>
 - fire a click event at the element.

4.11.5.2 <button>
 - fire a click event at the element.

4.11.5.3 <input>
 - if the element has a defined activation behavior, is to run synthetic click
activation steps on the element. Otherwise, it is just to fire a click event at
the element.

4.11.5.4 <option>
 - If the command is of Type "radio" then it must pick the option element.
Otherwise, it must toggle the option element.

4.11.5.5 <command>
 - if the element has a defined activation behavior, is to run synthetic click
activation steps on the element. Otherwise, it is just to fire a click event at
the element.

4.11.5.6 <label accesskey="">
 - the same as the respective facets of the element's labeled control.

4.11.5.7 <legend accesskey="">
 - similar to the above

4.11.5.8 any element with accesskey=""
1. If the element is focusable, run the focusing steps for the element.
2. If the element has a defined activation behavior, run synthetic click
activation steps on the element.
3. Otherwise, if the element does not have a defined activation behavior, fire
a click event at the element.


so the definition varies a bit, but:
4.11.5.3 is actually just to fire a click event, because pre-click activation
steps will be done in the pre-handle-event phase and post-click activation
steps / canceled activation steps will be done in the post-handle-event-phase

this should apply even for synthetic click events, the spec says that it
shouldn't apply only for <command> if I'm reading it correctly

4.11.5.4 doesn't fire a click event, I haven't figured out why

4.11.5.6 and 4.11.5.7 are special, they just forward click() to other element

4.11.5.8 just adds the focus step


http://www.w3.org/TR/DOM-Level-3-Events/ also specifies Activation event
synthesis (3.5.1)

so a synthetic click event is used to trigger activation and HTML5 says
activation id done in click() (8.2 Activation)

I hope, it's now a bit clearer :)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 3 July 2011 09:37:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:13 UTC