W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

RE: DOMActivate vs. Click

From: Jacob Rossi <t-jacobr@microsoft.com>
Date: Tue, 21 Jul 2009 21:16:14 +0000
To: Maciej Stachowiak <mjs@apple.com>
CC: Doug Schepers <schepers@w3.org>, Travis Leithead <travil@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <1FBDB72C331CBA4D815A8B85E1CBB65C025ECD@TK5EX14MBXC111.redmond.corp.microsoft.com>
Ok. That makes sense. Given that, is DOMActivate simply left in DOM L3 Events to support backwards compatibility with DOM L2 events? Or are there still use cases which it solves that other events do not?

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Tuesday, July 21, 2009 2:14 PM
To: Jacob Rossi
Cc: Doug Schepers; Travis Leithead; www-dom@w3.org
Subject: Re: DOMActivate vs. Click

On Jul 21, 2009, at 1:27 PM, Jacob Rossi wrote:

> As I understand it, the purpose of DOMActivate is to remove the device
> dependence of an element's associated behavior. So, clicking on a
> hyperlink causes a click event whose default action is to fire
> DOMActivate. The default action of the DOMActivate would then be to
> navigate to the page. Calling preventDefault() on either would prevent
> the navigation from occurring.
> I understand that associated activation behaviors can be invoked via
> different device interactions (using the keyboard while the link is
> focused). But if DOMActivate is supposed to remove the device
> dependence, why does the spec say: "when a user activates a hyperlink
> using a keyboard, the click event would be dispatched as default
> action of the respective keyboard event."
> Shouldn't it be that activating the hyperlink with the keyboard causes
> a DOMActivate event which is dispatched as the default action of the
> respective keyboard event? Otherwise, why have the DOMActivate event
> if the activation behavior is going to have some "default" event
> associated with it which all other device interactions are supposed to
> synthesize.
> It seems to me that firing a click event as the default action of an
> interaction via a device other than a mouse is not intuitive
> (especially since it is a MouseEvent and will have a number of
> associated attributes which are nonsensical).

You correctly described the original intended purpose of DOMActivate.

Unfortunately, Web compatibility requires sending a "click" event for non-mouse-driven activations. In particular, it is a common practice to give an <a> element or an <input type="button"> element an onclick attribute and the page author expects it to trigger even for keyboard activation. This practice precedes the existence of the DOMActivate event and remains common. Authors almost never use a DOMActivate handler instead.

Thus, it is necessary to still dispatch a "click" event for non-mouse activation.

Received on Tuesday, 21 July 2009 21:17:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:14 UTC