W3C home > Mailing lists > Public > public-xhtml2@w3.org > October 2010

Re: DOM3 Events last call comment

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 20 Oct 2010 21:03:37 -0700
Message-ID: <AANLkTimPeY=N=ts1QJ-p6OTB8aXB_wSe-43KjC4NitL9@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Steven Pemberton <Steven.Pemberton@cwi.nl>, www-dom@w3.org, Forms WG <public-forms@w3.org>, XHTML WG <public-xhtml2@w3.org>
On 10/20/10, 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.
>

Tell me if I got this wrong: I took "synonymous in all languages" to
mean that "click" and "activate" do the same thing in all DOMs (SVG,
HTML, MathML (?)).

> 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.
>

Move DOMActivate somewhere else, somewhere non-normative, like a draft.

> 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.
>

How does a program differentiate a pointer-triggered "click" from a
"touch" triggered click?

Garrett
Received on Thursday, 21 October 2010 04:04:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 21 October 2010 04:04:29 GMT