W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2010

DOM3 Events last call comment

From: T.V Raman <raman@google.com>
Date: Wed, 20 Oct 2010 16:32:15 -0700
Message-ID: <19647.31743.77233.278671@retriever.mtv.corp.google.com>
To: Steven.Pemberton@cwi.nl
Cc: www-dom@w3.org, public-forms@w3.org, public-xhtml2@w3.org

Also, note that W3C is now talking of creating a touch
interaction WG as part of the rich web activity. On the  present
Dom3 direction, we'll soon have "stroke" and maybe "massage"
events -- this is just plain wrong.

DOMActivate  is interaction agnostic --- let's not return to the
interaction equivalent of the blink tag :-)  or said differently,
this logic appears blurred if not flawed:-)  (and no, no more
onblur either please)

Steven Pemberton writes:
 > 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 Wednesday, 20 October 2010 23:32:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:06 GMT