Re: DOMActivate vs. Click

On Jul 26, 2009, at 8:47 PM, Doug Schepers wrote:

> Hi, Boris, Jonas-
> Okay, thanks for articulating the value of removing them.  I still  
> don't agree with the conclusion, because I know there is content  
> using them for SVG and XForms, and focus and blur aren't quite the  
> same as DOMFocusIn and DOMFocusOut, but I do respect why you see the  
> desire to remove them.  All I was hearing before was, "I'd really  
> like to remove them", which wasn't a satisfying argument.

For what it's worth, I roughly agree with Jonas and Boris's line of  
reasoning. Complexity of the Web platform has significant costs, and  
it's particularly bad in the case of events where the processing model  
is quite tricky in the first place. For mouse and keyboard events, we  
have to live with the complexity of multiple events per action because  
there truly are independent use cases, and heavy compatibility  
burdens. But as we've seen, it's very hard to specify all the  
interactions in a way that is sound and actually leads to true  

DOMActivate and DOMFocusIn/DOMFocusOut don't really serve independent  
use cases. So their complexity is pure trouble for implementors and  
authors. The only possible tradeoff would be compatibility with  
existing content, and I tend to agree with others here that walled  
garden content should not get much consideration. Walled garden user  
agents are always free to dispatch whatever extra events they choose.

> My current plan is still to deprecate them from DOM3 Events, not  
> remove them.  Implementations can then make the choice of supporting  
> them or not.  Personally, I hope you take a good look at possible  
> conflicts with content before you make a final decision.

If the events are optional for implementations (and it sounds like  
that is what you mean by deprecated), then WebKit will probably align  
with the judgment of other browser engines on whether to keep them. I  
hope it's ok to continue having that conversation among browser engine  
implementors here, even if leaving definitions for the events in the  
spec is the right way to go.


> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
> Jonas Sicking wrote (on 7/26/09 8:18 PM):
>> On Sun, Jul 26, 2009 at 7:31 PM, Doug Schepers<>   
>> wrote:
>>> Hi, Folks-
>>> Can someone please enlighten me why removing DOMFocusIn,  
>>> DOMFocusOut, and
>>> DOMActivate from existing implementations seems like a good idea?
>> Boris explains it really well.
>> To me it is really high value to cut "unfortunate" features when ever
>> we can. And to do so as soon as possible before too much content  
>> start
>> depending on it. There is always some amount of complexity that we
>> immediately remove by doing this. And long term it is likely that
>> it'll save us more complexity since it makes it easier to add future
>> features. It is especially the future features that I worry about
>> since we have no idea what feature today turns out to be a roadblock
>> for other work tomorrow.
>> For example being able to set document.domain I'm sure seemed like a
>> small change in the past, however it turned out to be a major  
>> headache
>> for supporting a namespace-resolver argument to querySelector.
>> / Jonas

Received on Monday, 27 July 2009 03:00:36 UTC