- From: Doug Schepers <schepers@w3.org>
- Date: Sun, 26 Jul 2009 22:47:01 -0400
- 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. 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<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