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

Re: DOMActivate vs. Click

From: Doug Schepers <schepers@w3.org>
Date: Sun, 26 Jul 2009 22:47:01 -0400
Message-ID: <4A6D1525.2030409@w3.org>
To: Jonas Sicking <jonas@sicking.cc>
CC: Anne van Kesteren <annevk@opera.com>, Jonathan Watt <jwatt@mozilla.com>, Olli Pettay <Olli.Pettay@helsinki.fi>, Jacob Rossi <t-jacobr@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Travis Leithead <travil@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, Andrew Sledd <Andrew.Sledd@ikivo.com>, Robin Berjon <robin@berjon.com>, Lee Martineau <lee.martineau@quickoffice.com>
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.

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.

-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<schepers@w3.org>  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 02:47:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC