Re: DOM3 Events last call comment

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.

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

Received on Thursday, 21 October 2010 03:20:48 UTC