Thoughts on DOMActivate

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'


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

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

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