W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: CfC: FocusEvent Interface

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 22 Sep 2009 22:17:24 -0700
Message-ID: <c9e12660909222217l47bdec6fgb32fa6a82e9573f4@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: "www-dom@w3.org" <www-dom@w3.org>
On Tue, Sep 22, 2009 at 9:27 PM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Maciej-
>
> Maciej Stachowiak wrote (on 9/22/09 9:34 PM):
>>
>> The FocusEvent interface itself seems fine, and a good solution.
>
> Thanks for the suggestion.  You were on the money.
>
>
>> I do think it would be worth doing some cursory research to determine
>> whether it is a problem to support "focusin" and "focusout" events
>> without 100% API compatibility with IE. Do sites only use these in
>> IE-specific code paths currently, or is it possible that they register
>> and use IE-specific APIs?
>
> As Garrett alluded (IIUC), they might even use the presence of these
> attributes to detect the feature for slipping into that code path.  Not a
> great practice, but there you have it (and admittedly better than browser
> sniffing).
>
>
>> These questions are relevant, because we may want to support IE's
>> toElement and fromElement attributes in the standard, depending on the
>> results.
>
> Sadly, I agree.
>
> Garrett's analysis seems pertinent here.  It would be good to research it a
> bit deeper to make sure it actually does cause the problems he described.
>

If there is no "onfocusin" property, and the event can only be
registered by addEventListener, then it would not break sites.

If the event can only be registered by addEventListener, then there is
a different problem. The problem that the "focusin" event listener is
not detectable. A program could not safely rely on it.

And so if the only mechanism to attach the delegating "focus" event
were through addEventListener, then a program would want to use more
widely supported approach of registering a capturing "focus" listener
and using "onfocusin" where not supported (the else clause for:-
if(el.addEventListener) {
  // capturing focus.
} else {
  // bubbling onfocusin
}).

OTOH, if an event handler property will exist, then will it break code?
http://www.google.com/codesearch?q=onfocusin+lang%3Ajavascript

I noticed things like SimpleAjax:
        if("onfocusin" in body) {  //if IE

That would still "work" if there were no event handler property (or at
least if [[HasProperty]] returns false for "onfocusin". Then there is
the typeof checks that might make such inference. Then there are the
codes that add both onfocusin and a capturing listener (PPK code).

Inferences like that make code fragile and make the web fragile.

The jQuery validator plugin (bassisstance.com). That one might get
away with its existing implementation and not have errors, though I
did not dig too deep (time):
http://bassistance.de/jquery-plugins/jquery-plugin-validation/

The way to register delegating focus blur is to use a capturing
listener -- works in all but IE, which ahs onfocusin/onfocusout.

Onfocusin is a fine idea. The problem is with existing programs that
use poor inferences and assumptions causing compatibility issues with
this (and potentially other) new features. Proper feature detection is
a big deal.

Garrett
Received on Wednesday, 23 September 2009 05:18:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT