Re: DOM3 Events last call comment [ISSUE-170]

Hi, Steven-

Thanks for your comment.

We discussed this issue at the DOM3 Events telcon today [2], along with 
James Craig, whose UI Independence for ARIA proposal you cited.

We agree that there is a need for a high-level event abstraction which 
encompasses the device- or hardware-level events; there are a number of 
different terms for this idea, such as Semantic Events, Intentional 
Events, Representational Events, etc.  I'm going to refer to all of 
them, for the purpose of this email, as "User-Action events"... things 
the user is trying to do, via whatever input-appropriate means.

There are a number of advantages to this approach:
* device independence: input devices which were not anticipated can 
still work as expected with existing code
* ease of authoring: authors can create robust webapps without digging 
into guessing what the user was trying to do through the UI devices
* separation of concerns: low-level device events can be mapped and 
repurposed to higher-level abstractions, even through mid-level 
intermediaries such as gestures, at either the implementation or 
authoring level
* localization: keyboard shortcuts, etc. can be appropriate to the 
language or OS without extra work by the author
* accessibility: webapps can function seamlessly with AT when the intent 
is clear on both the AT and webapp level
* and so forth ...

This approach is a better foundation on which to build webapps than the 
lower-level device-specific events defined by DOM3 Events, in many ways; 
note, however, that the device-specific events are also useful.

However, we do not feel that 'DOMActivate' is the appropriate event, 
neither as it was defined originally, nor as it is specified in DOM3 
Events today.  It relies on a complex relationship with 'click' that 
does not lend itself to simple authoring, as noted elsewhere.

We propose instead to deprecate 'DOMActivate', as planned, and to 
continue work with the PFWG and the new proposed Touch Interface WG 
(which may be renamed to Web Events WG) to build upon the UI 
Independence for ARIA spec and other related proposals to define this 
new abstraction layer with a set of associated User-Action events and an 
architecture that works well in browsers, which can suppress the events 
which triggered the User-Action event with stopImmediatePropagation() or 
something better (for example, a user hitting ctrl+z would first fire an 
'undo' event, so the webapp could stop the subsequent key event with the 
'Undo' value from muddying the waters), and which can be more easily 
adapted when these new events are not supported (hooks for script 
libraries are one such solution).  Whether we reuse the name 
'DOMActivate', or come up with a different name (maybe simply 
'activate'), is up for discussion; there are pros and cons either way.

If we do define the event as 'DOMActivate', to take advantage of its 
presence in other specs, implementations, and content, then it is to the 
advantage of that effort that it is deprecated from DOM3 Events, so it 
can be properly and canonically redefined in that spec; if we do not 
reuse the name, then it might be suggested that e.g. 'activate' and 
'DOMActivate' be treated synonymously in implementations.

So, in short, 'DOMActivate' was a good idea with a suboptimal execution 
and unfortunate timing, and a lack of supporting infrastructure, leaving 
it with a challenging legacy.  With the genuine recent interest by 
developers in making device-independent code (for mobiles, desktops, 
TVs, etc.), we are confident that a fresh start can be more successful 
this time around.  This effort will launch presently, in parallel with 
wrapping up DOM3 Events, and James Craig and I will be actively 
collaborating; this is the solution we have arrived at with the PFWG, 
and I hope that it also suits you and your groups.

Please let us know whether or not you are satisfied with this resolution.

[2] http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0095.html

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


Steven Pemberton wrote (on 10/18/10 8:23 AM):
> In section
> http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMActivate
> it says
>
> "Warning! The DOMActivate event type is defined in this specification
> for reference and completeness, but this specification deprecates the
> use of this event type in favor of the related event type click. Other
> specifications may define and maintain their own DOMActivate event type
> for backwards compatibility."
>
> This is the wrong approach, and should not be done.
>
> In the decade since DOMActivate was introduced markup languages have
> adopted DOMActivate as the 'proper' abstract device-independent version
> of activation, and it has been widely implemented, and adopted in
> documents.
>
> Having to rename all uses of DOMActivate will involve a lot of editing,
> a lot of re-educating and a lot of re-tooling.
>
> The advantage of a centrally standardised DOMActivate is that it is
> interoperable and works cross-namespace having the same semantics
> everywhere. If each namespace has to define its own DOMActivate, making
> generic markup that will work across namespaces will be hard-to-impossible.
>
> Another problem is that if true hardware events, like click, get mixed
> up with the abstract events like DOMActivate, then it will be harder to
> differentiate between hardware events when you need them, and abstract
> events when you don't.
>
> As Apple's resent proposal to W3C[1], discussed on the Hypertext
> Coordination Group, the correct way to process events is to process the
> hardware events when you need to, and to use the abstract events when
> you can.
>
> Deprecating DOMActivate is going in the opposite direction, is a
> retrograde step, and should not happen.
>
> Best wishes,
>
> Steven Pemberton
>
> User Interface Independence for Accessible Rich Internet Applications
> http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html
>

Received on Thursday, 21 October 2010 06:12:21 UTC