- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 21 Oct 2010 02:12:10 -0400
- To: Steven Pemberton <Steven.Pemberton@cwi.nl>
- CC: www-dom@w3.org, Forms WG <public-forms@w3.org>, XHTML WG <public-xhtml2@w3.org>
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:20 UTC