Re: DOM3 Events last call comment

On Thu, 21 Oct 2010 05:19:54 +0200, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Oct 18, 2010 at 5:23 AM, Steven Pemberton
> <Steven.Pemberton@cwi.nl> wrote:
>> 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.
>
> The problem is that 'click' *already* has the same meaning as
> DOMActivate does. If we were to stop dispatching 'click' events when a
> button or link was activated using the keyboard that would reduce
> accessibility for an enormous number of pages on the web since it
> would result in those pages not "working" when keyboard navigation was
> used.
>
> As things stand today the 'DOMActivate' and 'click' events are
> synonymous in HTML and this fact is relied on by millions of websites.
> This leaves us with a few choises:
>
> 1. Stop dispatching 'click' in HTML when keyboard is used to activate
> an element. This makes keyboard activation impossible on millions of
> websites.
>
> 2. Keep both 'DOMActivate' and 'click' and define that they work one
> way in HTML and another way in other languages. This means that
> authors that transition from authoring HTML to authoring other
> languages run risk of creating content which doesn't allow keyboard
> activation. We'd also have to define what happens in mixed content
> documents, such as SVG-in-HTML content.
>
> 3. Keep both 'DOMActivate' and 'click' and define that they are
> synonymous in all languages. This leaves us with a redundant feature
> which is of little value to anyone.
>
> 4. Keep both 'DOMActivate' and 'click' for now, deprecate DOMActivate
> from the DOM-Events spec but still allow other specs to use it if they
> so choose. This means that if other specs choose to also deprecate
> DOMActivate, authors using those specs will have to migrate to using
> 'click'. If other specs choose not to deprecate 'DOMActivate' then
> authors can keep doing what they've always done.
>
> 5. Something else.

Nuke DOMActivate from orbit and replace it with click.

Also see http://www.w3.org/Bugs/Public/show_bug.cgi?id=10899


> It sounds to me like you are saying that we shouldn't do 4. It's
> however unclear what you are proposing we should do instead.
>
> / Jonas
>


-- 
Simon Pieters
Opera Software

Received on Thursday, 21 October 2010 07:04:00 UTC