- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 26 Jul 2009 20:59:46 -0600
- To: Doug Schepers <schepers@w3.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, Jonathan Watt <jwatt@mozilla.com>, Olli Pettay <Olli.Pettay@helsinki.fi>, Jacob Rossi <t-jacobr@microsoft.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>
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 interoperability. 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, Maciej > > 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 03:00:36 UTC