- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 20 Oct 2010 21:03:37 -0700
- 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:30 UTC