DOMActivate vs. Activation Behavior

Hi, PFWG-

I had a nice chat with Gregory Rosmaita the other day, and he and I 
cleared up some possible disconnects on both our parts regarding the 
deprecation of 'DOMActivate'.  I incorporated the fruits of our 
discussion in the current editor's draft of the DOM3 Events spec [1], 
which I hope clarifies not only the details of activation behavior, but 
the intent and implications of deprecating 'DOMActivate'.

Here are a couple more important points that Gregory advised me to 
emphasize:

* 'DOMActivate' is not the same as "activation behavior".  Deprecating 
the 'DOMActivate' event type does not imply removing "activation 
behavior" (note that activation behavior is not defined merely in terms 
of event flow, but in terms of user and UA behavior, as well).  On the 
contrary, I have expanded and clarified activation behavior, with a much 
more precise and interoperably-implementable definition that 
distinguishes between activation triggers and activation behavior, with 
clear instructions on how a "host language" (i.e. a markup language 
which uses DOM3 Events) should specify any activation behaviors for that 
language, and a ordered list of events and default actions that UAs must 
follow sequentially to correctly allow for activation, in particular 
with regards to keyboard activation.

* With regards to the vernacular use of "click", especially in other 
languages, a distinction must be drawn between how people speak about a 
user interface and what event types correspond to those user actions. 
For example, it's common to say "press the 'Enter' key", but the 
'keypress' event does not register events on the 'Enter' key, only 
events from character-producing keys; thus, developers must use the 
'keydown' event type.  Providing developers with clear instructions 
regarding the necessary jargon is the way to yield consistent user 
experience, and I believe the current DOM3 Events spec does that with 
regards to device-independent activation.  The name of the event type is 
unfortunate, but inconsequential.

* Existing content and languages which use 'DOMActivate' should not be 
adversely affected by this; languages which use 'DOMActivate' (such as 
XForms) can continue to define that event type going forward [2].

* The most important goal here is to make sure that all users are able 
to benefit from equal access; insisting that authors use 'DOMActivate' 
rather than 'click' makes content creation more difficult, and in fact 
ghettoizes users of AT to those sites and UAs that use 'DOMActivate' 
(and those resources are very few).


[1] 
http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-flow-activation 

[2] 
http://lists.w3.org/Archives/Public/public-hypertext-cg/2010JanMar/0002.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 8 February 2010 09:20:42 UTC