Re: Deprecating DOMFocusIn/DOMFocusOut (was: DOMActivate vs. Click)

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:45 UTC