Re: DOM3 Events last call comment

On 10/20/10, Jonas Sicking <> wrote:
> On Mon, Oct 18, 2010 at 5:23 AM, Steven Pemberton
> <> wrote:
>> 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
>> 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?


Received on Thursday, 21 October 2010 04:04:11 UTC