Re: DOM3 Events last call comment

On Wed, Oct 20, 2010 at 9:03 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> 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 (?)).

That the two events are always fired together in all DOMs, yes. I.e.
If you use the mouse or keyboard to activate an XForms element or SVG
element, always fires both DOMActivate and click.

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

How does one now? Do you have proposals?

/ Jonas

Received on Thursday, 21 October 2010 04:33:24 UTC