Re: CfC: FocusEvent Interface

On Tue, Sep 22, 2009 at 4:26 PM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Garrett-
>
> Garrett Smith wrote (on 9/22/09 5:12 PM):
>>
>> On Tue, Sep 22, 2009 at 10:28 AM, Garrett Smith<dhtmlkitchen@gmail.com>
>>  wrote:
>>>
>>>  On Tue, Sep 22, 2009 at 12:40 AM, Doug Schepers<schepers@w3.org>  wrote:
>>>>
>>>>  As discussed on this list and in the telcon, I've added a new
>>>> FocusEvent
>>>>  interface with a 'relatedTarget' attribute, moved focus events there,
>>>> then
>>>>  moved Basic Events to UIEvents cuz DOMActivate was lonely, and removed
>>>> the
>>>>  Basic Events category.
>>>>
>>>>  You can see my handiwork in the latest ED:
>>>>
>>>  It would be nice if you would defer creating technical APIs to those
>>>  who are qualified (instead of trying to do it yourself).
>>>
>>
>> Sorry, that was inflammatory and a little insulting.
>
> Just a little. :)
>
> FWIW, I've written quite a few commercial Web applications, so I have a
> reasonable sense of how the average author might expect things to behave.
>  I'm not always right, which is why I solicit feedback from others on this
> list.
>
> In practice, I've not had much luck with getting feedback in a timely
> manner, prior to putting it in the spec.  My requests for feedback on this
> list have yielded relatively few replies... unless I do the work of putting
> it in the spec first, which apparently is enough of a "threat" that some
> people pay attention and comment if I've totally messed it up.  It's
> suboptimal from my point of view, but may be inevitable... people want
> something concrete to comment on, in part.
>
> Thus, I attempt to not be afraid on making a mistake on my first pass... I
> want the feedback, and it seems the best way to do that is to edit the spec
> ("worse is better"), and iterate quickly through the review and mistakes and
> corrections.
>
> But that also means that by the time I've digested what I have learned about
> the topic at hand, and stepped through the process of speccing it out, I
> cement my own opinions somewhat.  So, I'm not necessarily inclined to
> revisit decisions unless there is a clear sense that there is a better way
> to do it.
>
> I do try to take constructive feedback into account, especially if it's
> concrete; I expect others do shoulder some of the burden, if they want
> things changed.  I think that's reasonable.
>
> Speccing the focus events is an instance where I made a few decisions based
> on research (mine and others), and made a bad call on one of them (adding
> focusin/focusout was good, misusing currentTarget was stupid). Maciej,
> Jacob, Olli, Travis, and others advised me how to fix it, and during the
> telcon we resolved to make the FocusEvent interface and move the focus
> events there.  So this is not an API decision I made myself... it's the
> result of that iterative process.  It's probably not done, though I hope it
> is.
>
> Having done that, I also chose to move the Basic Events Module event types
> into the UIEvents interface because they are all defined as using UIEvents
> (at least sometimes), because the only event left in UIEvent was
> DOMActivate, and because unlike all the other event types, they were not
> collected under an interface (from a spec organization perspective).  If
> that's a mistake, I'm happy to revisit it, and to move them wherever they
> fit better.  In this instance, I don't think it causes any harm, it makes a
> certain degree of sense, and it makes the spec a little more readable.
>
> There's my editorial process in a nutshell.  Fast, cheap, and out of control
> [1]. :)
>
> Now, if I took the time to explain every decision in that level of detail
> (which is just reiterating the results of the email on www-dom and
> discussion in the telcons), I wouldn't be left with any time to actually
> edit the spec.  I'm not trying to be rude, but if we want to get this spec
> to Last Call soon, there is a certain expectation on all of us to contribute
> and keep up.... www-dom is actually a pretty light load, for a mailing list.
>  (Except when I go into long, detailed emails.)
>
>
>>  I actually meant
>> to snip that out but forgot. I'd like to focus more on the researching
>> of the proposed feature.
>>
>> As mentioned here:
>>
>>>  http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0330.html
>
> I read that email when you sent it.  I read the article on QuirksMode that
> you referenced.  I did consider your comments.
>

Really? And what if the "onfocusin" is implemented?

Please explain the expected outcome of the code on quirksmode.

> I'll reply on a few points inline, here...

[...]

>
>
>> Will a new "onfocusin"  break sites that use loose inferences?
>
> Travis' and Olli's judgment during the telcon was that it wouldn't. (BTW,
> it's "focusin", not "onfocusin"... right now the DOM3 Events spec doesn't
> say anything about "on*" attribute event listeners.)
>

If there is no "onfocusin" there would not be a collision.

>
> As mentioned elsewhere, a script library [1] can emulate these events if
> they aren't supported natively.


By what means would a program make the determination of "not supported
natively"?

 Adding these events doesn't mean we are
> taking away any feature already in use (focus/blur), though we are
> deprecating DOMFocusIn/DOMFocusOut (for a different reason).
>
>
>> Please do a google code search to see how it is used in existing web
>> pages.
>
> This is not a concrete task, nor even a bounded one, nor did it seem (from
> our conclusions stated above), that it was necessary.  We did not anticipate
> conflicts (so, no negative results), and we aren't aiming to solve all
> problems, just the low-hanging fruit... onfocusin/onfocusout attribtutes are
> already implemented in IE, and only a slight adjustment will bring them into
> the current model (which they are willing to do), and they have been used
> with good results in many Web pages.  We can draw reasonable conclusions
> without an exhaustive Web search, for some set of issues.
>

If the new event is not going to have a corresponding event handler
property, it won't be detected, and will be virtually unused, just as
"domfocusin" is (I can't see why YUI is using it).

> If you are willing to do the work you suggest,

A google code search revealed that "onfocusin" is used extensively.
Introducing the property would cause conflict in existing code. It
would obviously not work with something like what PPK suggested, as it
would result in two callbacks being added in some implementations (the
callback would fire twice). If an implementation decides to implement
onfocusin event handler (and I may have read that in recent thread),
it will cause an error as described, in a lot of code, and an example
with the code from PPK site:

  $('dropdown').onfocusin = handleMouseOver;
  $('dropdown').onfocusout = handleMouseOut;
  $('dropdown').addEventListener('focus',handleMouseOver,true);
  $('dropdown').addEventListener('blur',handleMouseOut,true);

and come back with a concrete
> proposal that improves over the current model, you are welcome to help us
> out in that way.  But to be honest, I don't think this is necessary for us
> to progress on DOM3 Events.  Obviously, it could be helpful for future
> versions of the spec.
>

An onfocusin property for elements would probably break a fair number of sites.

A new "focusin" event will be useless until it can be detectable. part
of the problem with domfocusin. It would be unreasonable for a program
to rely on undetectable features.

An event handler by any name that does the same thing, and has a
corresponding DOM 0 event handler property:

The name could be ondomfocusin, or onuifocus, but not onfocusin,
because that would break existing programs that expect "onfocusin" to
be "MSIE only" (through use of poor or unrelated inference).

That allows the program to detect the feature in some implementations,
using the "isEventSupported" approach.

>
>> Please also see the delegating focus article on quirksmode.
>
> I did read it, and it was interesting, but nothing in it suggested we were
> on the on the wrong track.  Did you reach other conclusions?
>
>
>> Please do report back your findings.
>
> We discussed these issues, among many others, in email and in the telcons
> (the minutes of which are available to everyone).
>
> To be honest, I'm not sure what in that specific email struck you as
> particularly challenging to the decision that we settled on.  Where is the
> contraindication of the current design of the focus features in the spec?
>

I do not know what contraindication you meant.

Garrett

Received on Wednesday, 23 September 2009 00:03:31 UTC