- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 22 Jul 2009 15:35:01 -0700
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Doug Schepers <schepers@w3.org>, Anne van Kesteren <annevk@opera.com>, "wai-xtech@w3.org" <wai-xtech@w3.org>, Jacob Rossi <t-jacobr@microsoft.com>, Travis Leithead <travil@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, public-forms@w3.org
I don't have a strong feeling on whether DOMFocusIn/DOMFocusOut/ DOMActivate should be kept, but I think your history here is inaccurate. "focus" and "blur" have always been device-independent - they are nearly identical to the DOM-prefixed events, other than bubbling behavior. "click" has always been dispatched for all activations by browsers that support DOM events, so it's always been just as device-independent as DOMActivate. Whatever the reason was for creating the alternate events, I don't think it was accessibility. Or at least, if that was the reason, it was based on a serious misunderstanding. As for possible reasons to keep the events now that they exist: 1) Reliance by other specs. Some of these are specs that browsers are unlikely to ever implement, though, so any events needed solely for that purpose probably shouldn't be required as a baseline behavior for all of the Web platform, just to enable those particular specs. 2) Maybe there's content that depends on them in their non-IE code path. I don't think this is the case but I haven't tested. 3) "DOMActivate" is slightly different from "click", because it won't fire for a click that is not an activation. I could imagine a contrived use case where you set a "DOMActivate" handler at the root element to track all activations - "click" wouldn't work because you'd get a bunch of other clicks as well. But I don't know of anyone actually doing this, so I am not sure if it is a compelling use case. Regards, Maciej On Jul 22, 2009, at 3:18 PM, Charles McCathieNevile wrote: > IMHO, and cc'ing the WAI-xtech list to see if PF really agrees with > me. > > On Wed, 22 Jul 2009 23:05:25 +0200, Doug Schepers <schepers@w3.org> > wrote: > >> Hi, Anne- >> >> +public-forms@w3.org >> >> Anne van Kesteren wrote (on 7/22/09 9:35 AM): >>> On Tue, 21 Jul 2009 23:16:14 +0200, Jacob Rossi<t-jacobr@microsoft.com >>> > wrote: >>>> >>>> Ok. That makes sense. Given that, is DOMActivate simply left in DOM >>>> L3 Events to support backwards compatibility with DOM L2 events? Or >>>> are there still use cases which it solves that other events do >>>> not? >>> >>> I think the sole reason we have DOMFocusIn, DOMFocusOut, and >>> DOMActivate is political. I'm not sure if that changed to backwards >>> compatibility at this point, but I doubt it. > > They were created at a time when there were serious accessibility > problems > activating the relevant events through keyboard use, and it was a > compromise between fixing the more common events and doing nothing - > in > that sense it was indeed political. > > Since then, the original events have in fact been improved in > browsers, > and the reason for retaining these is back-compat (this was an early > decision of the old WebAPI WG) at the request of other groups. > >>> DOMFocusIn and DOMFocusOut have been retained on request of the >>> Forms >>> WG and for DOMActivate I do not really remember. Fact of the matter >>> is that focus/blur/click work fine and already are platform >>> independent and much better understood by authors of Web >>> applications. >>> >>> I'd be very happy if could consider yet again dropping >>> DOMFocusIn/DOMFocusOut/DOMActivate. > > I think it makes good sense to deprecate them, pointing out that > people > shouldn't keep using them but should use the improved originals. > (And it > only took ten years to get to this :) ). > > Likewise, the click event is now cross-platform and device- > independent, so the reason for a seperate DOMActivate is gone, and > that should also be deprecated. > > I haven't looked carefully at the impact on WCAG 2 yet, but the > impact on WCAG 1.0 is that the relevant checkpoints 6.4 [1] and 9.3 > especially, but also some others need not be updated. However the > techniques documents should note that it is possible to use the > focusin/out and click events because they are generally device- > independent in this way (mouseover, mousein/out by contrast are > still problematic). If someone could check this for WCAG2 it would > be helpful. > >> Taking a look at the current state of implementation [1], and >> seeing the similarity of function between IE's focusin/focusout and >> DOMFocusIn/DOMFocusOut, I have now included focusin/focusout, and >> deprecated DOMFocusIn/DOMFocusOut in favor of those event types. >> This is a tentative decision, but it seems logical to me; any >> comments are welcome. > > [1] http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-keyboard-operable-scripts > [2] http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-device-independent-events > > cheers > > Chaals > > -- > Charles McCathieNevile Opera Software, Standards Group > je parle français -- hablo español -- jeg lærer norsk > http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Wednesday, 22 July 2009 22:35:48 UTC