Re: CfC: FocusEvent Interface

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.

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


Garrett Smith wrote (on 9/17/09 1:04 AM):
>
> initUIEvent has 5 params, and initMouseEvent 15, so that would make it
> the sixth parameter for initUIEvent and the 16th of initMouseEvent.
>
> Would changing the method signature be backwards compatible? I think
> it would not.

Indeed, we decided against adding relatedTarget to UIEvent, splitting 
out the focus events to the new FocusEvent interface instead.  So, no 
problem there.


> 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.)


> What is the recommended practice for detecting this feature?

As I mentioned elsewhere, I don't think we've settled on that.  My 
preference would be a featurestring for each interface and event.


> When introducing the new feature, have you considered:
>    * How will the new feature will affect code in existing web pages?

Since nobody is now expecting focusin/focusout to have the 
.relatedTarget attribute, it seems unlikely that that aspect will affect 
code at all.


>    * How can the feature be detected?

See above.


>    * What sort of fallback mechanisms are available?

As mentioned elsewhere, a script library [1] can emulate these events if 
they aren't 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 you are willing to do the work you suggest, 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.


>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?

Without more specific and targeted comments, I didn't have any more to 
say than what everyone on this list can gather from reading the other 
emails and the spec.  I'm not going to respond to every email on this 
list (that's too time consuming), but I do read and consider them all. 
If you haven't gotten a satisfactory response, try restating the 
question another way and seeing if that clicks with someone on the list.

We're only human.


[1] http://www.errolmorris.com/film/fcooc.html
[2] http://www.extjs.com/forum/showthread.php?t=74974

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 22 September 2009 23:26:22 UTC