ISSUE-170 (DOMActivate deprecation): Consider not deprecating DOMActivate [DOM3 Events]

ISSUE-170 (DOMActivate deprecation): Consider not deprecating DOMActivate [DOM3 Events]

Raised by: Doug Schepers
On product: DOM3 Events

Steven Pemberton <>:
In section
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  

Deprecating DOMActivate is going in the opposite direction, is a  
retrograde step, and should not happen.

Received on Wednesday, 20 October 2010 16:57:56 UTC