Re: Deprecating DOMFocusIn/DOMFocusOut

Hi, Anne-

Anne van Kesteren wrote (on 7/23/09 6:42 AM):
> On Thu, 23 Jul 2009 12:30:38 +0200, Doug Schepers<schepers@w3.org>
> wrote:
>> Anne van Kesteren wrote (on 7/23/09 6:12 AM):
>>> What existing content? It is far more likely existing content
>>> uses focus and blur. At least as far as Web browsers are
>>> concerned and I think it would make sense to evaluate a solution
>>> for Web browsers here in isolation since not bloating the focus
>>> API would be great.
>>
>> SVG content uses DOMFocusIn, DOMFocusOut, and DOMActivate,
>> particularly on mobiles.
>
> Do you have pointers? Such content would fail in Opera, for
> instance.

http://schepers.cc/svg/events/DOMFocusActivate.svg

Indeed, DOMActivate doesn't work in Opera... I'll talk to Erik about 
that.  I'm still open to the idea of deprecating it, but I want to 
gather data beforehand.

Note that DOMFocusIn and DOMFocusOut do work, though, and I've seen SVG 
content that uses them in the wild.


>> I agree that not bloating APIs is a good goal, but unfortunately,
>> we have legacy implementations and content to deal with... remember
>> that bit about "backwards compatibility", and "paving the cowpaths"
>> (with regards to focusin and focusout), and "documenting existing
>> behavior"? Do you take those principles seriously, or not?
>
> They are principles, not black and white rules. Backwards
> compatibility for instance does not have to matter if only two
> relatively non-important pages depend on a certain behavior and we
> can greatly simplify the Web platform. Adding focusin and focusout
> has nothing to do with paving the cowpaths. Paving the cowpaths is
> about adopting certain authoring patterns, not proprietary features
> from a single vendor no other vendor thought are worth copying.

Actually, focusin differs from focus in that it happens before the focus 
is shifted, as has been recently discussed on this mailing list, and in 
the telcon.  This allows authors to intercept focus events, which was 
discussed as desirable.



>>>> but that all implementation should use the replacement events
>>>> instead. Unless they have a market need, implementations that
>>>> don't already support deprecated events should not support them
>>>> in future versions.
>>>
>>> Then I do not see much value in deprecation.
>>
>> Your employer expressed a different opinion on yesterday's telcon,
>> as have many other people.
>
> Charles and I indeed do not always agree. I'm sure the same happens
> in other companies.

Yes, but when I get conflicting messages from you and Chaals, I'm going 
to pick the one who has more authority to make decisions (in particular, 
implementation decisions) at Opera.  That seems to be Chaals.


> I have actually seen support on this mailing list for not
> complicating matters further and support for simplifying matters, if
> feasible. From Maciej, Boris, and Stewart; all implementors.

Actually, Maciej said he doesn't have a strong feeling on the matter.

Honestly, I don't mind removing focusin and focusout again, but your 
arguments do not seem to be based on a logical examination of what might 
help authors, but rather you seem to simply be reasserting your preference.

I have deprecated DOMFocusIn and DOMFocusOut, and am willing to 
deprecate DOMActivate if the evidence shows that it's not needed and the 
WG decides to do so, but your arguments so far have been rhetorical and 
unpersuasive.  Please, show us some data, like from Opera's MAMA, so we 
can make an informed decision.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Thursday, 23 July 2009 11:30:31 UTC