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

> 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.
To do this, one would want to use capture (to make sure another listener didn't cancel the propagation). However, if you use capture you still have no guarantee that the DOMActivate actually resulted in an activation (another listener could call preventDefault() )-- so you're no better off. If I understand you correctly, that was the intention of your proposed use case (detecting when an activation actually happens as opposed to just random clicks).

Furthermore, web apps are blurring the lines of what elements have activation behaviors. Many sites today are providing "activation behaviors" which are the result of click events that did not occur on an element with an officially associated activation behavior.

--Jacob

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Wednesday, July 22, 2009 3:35 PM
To: Charles McCathieNevile
Cc: Doug Schepers; Anne van Kesteren; wai-xtech@w3.org; Jacob Rossi; Travis Leithead; www-dom@w3.org; public-forms@w3.org
Subject: 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-s
> cripts [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 Thursday, 23 July 2009 00:11:58 UTC