Fwd: Re: Agenda+Deprecating DOMActivate Event

Forwarded for public viewability.

-------- Original Message --------
Subject: Re: Agenda+Deprecating DOMActivate Event
Date: Wed, 20 Jan 2010 16:07:19 -0500
From: Doug Schepers <schepers@w3.org>
To: Steven Pemberton <Steven.Pemberton@cwi.nl>
CC: HCG <w3c-html-cg@w3.org>

Hi, Folks-

Steven Pemberton wrote (on 1/20/10 10:41 AM):
> Doug Schepers has been sending a message around about the possible
> deprecation of DOMActivate [1], and it seems to me to be an ideal topic
> for discussion in HCG.
>
> [1] http://lists.w3.org/Archives/Public/www-dom/2010JanMar/0004.html

Yes, let me provide some background before the call...

After talking with implementers and other groups with a stake in
"DOMActivate" (such as the XForms, VoiceXML, SVG, and accessibility
folks), I determined that "DOMActivate" was not only not strictly
necessary, but could be considered harmful, and thus I deprecated it in
the most recent editor's drafts of the DOM3 Event specification [2].  I
started out very skeptical of this change, and opposed deprecating it
(or removing it, as some wished), but was convinced by merit of argument
[3] that it was the right path for DOM3 Events.

Why might it be harmful?

1) It is inconsistently implemented, which means that content authors
cannot rely upon it in all UAs

2) Where it is implemented, it has an unusual dependency relationship
with the "click" event, causing an increase in complexity for
implementers and authors, which in turn leads to uncertain results and
potential non-interoperability

3) Authors have often been advised to use "DOMActivate" rather than
"click", with the rationale that it was more device-independent and
accessible; however, in the time since "DOMActivate" was defined, the
"click" event has been changed in browsers so that it is more
accessible, while "DOMActivate" has not been widely implemented (in
browsers, at least), or much used in content, with this result:

3a) Authors who follow advice to use "DOMActivate" instead of "click"
are actually making their content *less accessible* to most browser users

3b) Advising authors to change their practices to use "DOMActivate"
instead of "click" reaches only a small number of authors out of a vast
pool, while changing the small number of browsers to have more
accessible "click" functionality positively affects the landscape for AT
users and doesn't force authors to needlessly change their current
practice.  (If the mountain won't come to Muhammad...)


It's worth noting that the term "click" has become generic in the
vernacular, as well... to click a link or button means to activate it,
with little or no lingering connotation of a mouse device (cf. mobile
browsers, touchpads, etc.).  This isn't particularly consequential to UA
behavior, of course, but makes it easier to train new authors when they
are already familiar with a term.


Languages which wish to retain the "DOMActivate" event type may continue
to do so, of course; it will simply not be considered one of the "shared
event types" common to the majority of languages using DOM3 Events.

Note that there are perfectly legitimate uses of
"activate"/"DOMActivate" in languages like XForms that are distinct from
the accessibility case most important in browsers and browser content.
Since "click" denotes user behavior, this is not always appropriate
(semantically or logically) to the behavior of events in XForms.  By
removing the unfortunate implicit connection between "click" and
"DOMActivate", and deprecating it in DOM3 Events, XForms is now free to
define behavior that better fits its model (for example).

It may well be that "DOMActivate" and other event types might be shared
between different languages/specs (for example, XForms and VoiceXML),
and that they would benefit from coordination.  If this case arises, it
would be perfectly appropriate to develop a spec around those event
types, which could normative reference the event interface and
propagation model of DOM3 Events spec while being distinct from it; that
seems like a sound modular approach.


Finally, the decision to deprecate "DOMActivate" in DOM3 Events is not
carved in stone; if sufficient rationale is given against deprecating
it, this decision can change.


[2]
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMActivate
[3] http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0099.html

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

Received on Monday, 1 February 2010 08:34:51 UTC