Re: Deprecating DOMFocusIn/DOMFocusOut

On Thu, 23 Jul 2009 13:30:18 +0200, Doug Schepers <schepers@w3.org> wrote:
> 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:
>>> 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

I thought by SVG content you meant something other than test cases, did I misunderstood?


> 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.

Just deprecating would not simplify anything.


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

I would appreciate pointers.


>>> 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.

That is a different argument and I fail to see the connection to what I said.


> This allows authors to intercept focus events, which was  
> discussed as desirable.

I'm willing to believe that, but before we add new features it would be good to have the use cases documented. You put this forward initially as doing focusin and focusout because IE did it. Then it became a cowpath and now it turns out they might be slightly different in behavior, but it is still not clear whether they are worth it.


>> 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.

Your call, I suppose. I would prefer if you based your reasoning on merit rather than authority.


>> 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.

That is not all what he said, but I suppose I should not speak for others. My apologies.


> 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'm basing my arguments on the data provided so far.


> 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.

That is not a very nice thing to say without explaining why you think this is so.


> Please, show us some data, like from Opera's MAMA, so we  
> can make an informed decision.

I'll look into it.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 23 July 2009 11:58:19 UTC