Re: Deprecating DOMFocusIn/DOMFocusOut

On Jul 23, 2009, at 3:30 AM, Doug Schepers wrote:

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

Let's set aside deprecation for a moment and talk about UA  
requirements. Out of the following pairs of events, which will be MUST- 
level requirements for implementations of DOM Level 3 Events to  
dispatch on focus changes? Which will be MAY-level optional  
requirements? And which will be forbidden (MUST NOT)?

1) focus / blur
2) DOMFocusIn / DOMFocusOut
3) focusin / focusout

I would suggest only #1 should be a MUST-level requirement, and the  
other two should be MAY-level requirements.

#1 is needed for web compatibility - I don't think anyone disputes  
that. #3 is provably not needed for web compatibility, since currently  
no implementation supports both the #3 set of events and  
addEventListener(). Thus there can't be content depending on listening  
for those events via addEventListener(). #2 seems somewhat unlikely to  
be needed for web compatibility, since Opera does not support it and  
apparently hasn't seen a problem so far, other than in artificial test  
cases. It's possible SVG content may use it, but we don't have  
evidence that this is widespread. Thus I think there is no  
justification for making #2 and #3 mandatory for implementors.

If we find evidence that content depends on #2, I think it would be  
reasonable to consider making it a MUST-level requirement.

I would not consider it acceptable to make all three mandatory to  
implement. That would be needless complexity for no gain in web  
compatibility. I would also not consider it acceptable to leave it  
unspecified which of these are mandatory and which are optional; there  
has to be at least one pair of events authors can count on. Also, it  
would not make sense to have a MUST NOT requirement, since  
implementations are always allowed to dispatch whatever extra events  
they like. Thus, a possible alternative to a MAY requirement is to  
just not mention the other events at all, but it seems like a good  
idea to require that *if* a UA implements these events, then it must  
do so according to a particular processing model.

Regards,
Maciej

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