Re: Thoughts on DOMActivate

On 11/19/09 6:21 PM, Travis Leithead wrote:
> As discussed on the recent working group call, I mentioned that I needed
> to do some investigation into DOMActivate.
>
> (Attached are a few HTM files that demo the points made below.)
>
> Activate.htm tests the following types of elements that might/could fire
> DOMActivate:
>
> 1. Focusable elements
>
> <div tabindex="1">Some block content</div>
>
> 2. Buttons (was mentioned explicitly)
>
> <div><button>A button to click on</button></div>
>
> 3. Anchors (sans href attribute)
>
> <p><a>A link to click on (sans href set)</a></p>
>
> 4. Anchors (with href attribute)
>
> <p><a href="javascript:void">Another link to click on</a></p>
>
> Per Firefox Testing:
>
> Using MouseClicks
>
> 1> 'click'
>
> 2> 'click', 'DOMActivate'
>
> 3> 'click'
>
> 4> 'click', 'DOMActivate'
>
> Using the Keyboard
>
> 1> 'keydown'
>
> 2> 'keydown', 'click', 'DOMActivate'
>
> 3> n/a (not default focusable)
>
> 4> 'keydown', 'click', 'DOMActivate'
>

Actually, IIRC, it is keypress which fires click.

> Hypothetically, if the standard deprecates 'DOMActivate' as has been
> discussed, These two scenarios would look like this:
>
> Using MouseClicks (click for DOMActivate)
>
> 1> 'click'
>
> 2> 'click'
>
> 3> 'click'
>
> 4> 'click'
>
> Using the Keyboard (click for DOMActivate)
>
> 1> 'keydown'
>
> 2> 'keydown', 'click'
>
> 3> n/a (not default focusable)
>
> 4> 'keydown', 'click'
>
> So,
>
> 1) In cases where you use the keyboard or the mouse to perform an
> activation (cases 2 and 4) click can be used fully in place of
> DOMActivate with no issues. It will also be triggered for
> non-activations which could be an issue.
>
> 2) In cases where you wanted to detect that an activation behavior was
> about to be triggered, you can no longer distinguish between a regular
> click and a click that is a result of an activation. E.g., when using
> the mouse as your input device you can't tell when an activation
> behavior will occur for anything...
I'm not quite sure what you mean here.
If there is DOMActivate, some event listener could call preventDefault 
on that, the similar way as with click.


>
> For (2) this could be considered a "good thing" or a "bad thing". It
> could be considered good if you want to abstract away the concept of
> "activate" to that web apps don't need to care about it--they handle
> everything through 'click'. It could be a bad thing if you feel that a
> web app should know when some "activation" happens.
>
> For buttons, radio buttons, checkboxes, etc., the activation behavior
> seems rather redundant, since event handlers for 'click' are going to
> check the state of the element themselves (this.value or
> this.checked)--Canceling the 'click' event in these scenarios already
> revert the changed value (has identical behavior as DOMActivate in these
> scenarios).
>
> For links, there's already a catch-all that can (and is) used to stop
> the default value of the activation--even after DOMActivate has
> successfully completed--and that is 'beforeunload'.
What is wrong with adding 'click' listener to window? That
would catch all the click events and could call preventDefault()
(and maybe stopPropagation() if needed, depends on the phase the 
listener was added to).


>
> An additional test is attached [activate2.htm] for showing that
> beforeunload can be used in place of DOMActivate to stop
> navigations--The drawback is that to use it, a dialog is displayed to
> the user (no silent link blocking--which may be a good thing from a
> user-perspective anyway).
>
> I remain open to scenarios that prove the need for DOMActivate, but seem
> to find that it's largely irrelevant (except for legacy dependencies, of
> course).
>
It is indeed difficult to find good real-world use cases for 
DOMActivate. click works usually just well enough.


-Olli

Received on Wednesday, 25 November 2009 18:37:20 UTC