RE: DOMActivate vs. Click

Hi Doug,

>From a big picture perspective I think the comments from Boris covered things quite nicely.  

In the SVG mobile world, we have seen proprietary content using the DOMfocus events, but whether there is a 'significant' amount of usage is hard to say.

In the short term it does not matter, it has been implemented and we will continue to support it in the context of SVGT1.2.

In the long term, your plan to deprecate rather than remove sounds like a reasonable approach.

--
Lee


> -----Original Message-----
> From: Doug Schepers [mailto:schepers@w3.org]
> Sent: Sunday, July 26, 2009 10:47 PM
> To: Jonas Sicking
> Cc: Anne van Kesteren; Jonathan Watt; Olli Pettay; Jacob Rossi; Maciej
> Stachowiak; Travis Leithead; www-dom@w3.org; Andrew Sledd; Robin Berjon;
> Lee Martineau
> Subject: Re: DOMActivate vs. Click
> 
> 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 14:01:21 UTC