Re: Deprecating DOMFocusIn/DOMFocusOut

Hi, Nick-

Nick Van den Bleeken wrote (on 7/23/09 8:21 AM):
>
> This e-mail is my personal opinion and not that of the Forms WG
> (we're having a small break due the amount of people that are
> currently on vacation).

Thanks for chiming in.  I look forward to hearing back more from the 
Forms WG when everyone is back.


> Almost all XForms documents will use DOMActivate because there is for
> example no other way to link an action to a trigger (button, hyper
> link, ...).

I wonder if this might be a disconnect because of the name of the 
events?  'click' acts like DOMActivate in browsers... I have a small 
example that might set the context. [1]

Using just the keyboard, if I tab to the button and hit the "return" or 
"space" key, it will fire either or both of a 'click' or 'DOMActivate' 
event.  I know, these are HTML forms, not XForms, but I wonder if they 
might not be treated as the same for this mode of access?


>Due to the fact that XForms is language and device
> independent controls aren't always activated by clicking on them
> (e.g. voice, enter key, ...) or are only activated by double clicking
> on them. These are only examples the way you activate a control
> depends on the control, the device, input method,... So I think there
> is a difference between the click and DOMActivate event, multiple
> click events could result in a single DOMActivate event and
> DOMActivate events can occur without a click event.

I'm treading on the ice of ignorance here, but since XForms isn't a 
rendering language, shouldn't that prevent the "collision" of 'click' 
and 'DOMActivate'?  That is, 'click' doesn't seem to me that it is used 
in XForms at all, so couldn't it be used instead of (or in addition to) 
'DOMActivate'?


> DOMFocusIn and DOMFocusOut are used less frequent then DOMActivate in
> XForms but they are used because these are the only focus related
> events an XForms implementation must dispatch. XForms is host
> language independent therefore we don't know if the host language
> uses focus and blur.

Since you seem to be using 'DOMFocusIn' and 'DOMFocusOut' (and 
'DOMActivate', for that matter) as essentially abstractions of the 
underlying events of the host language, shouldn't that mean that the 
actual host language events could be mapped just as well to 'focus', 
'blur', and 'click'?  I'm not making an assertion, just asking the question.


>Secondly focus and blur don't bubble and there
> are cases where you want your action to be ran after the any of your
> handlers in the capture phase, the target phase and the default
> action. This isn't possible when using focus and blur.

It would be useful to see examples of this, to see if there is another 
pragmatic way of satisfying the use case.  In particular, I'm wondering 
if the 'focusin'/'focusout' events would solve it, since those are 
implemented in IE, and they also bubble.

I'm not rejecting your input, just trying to dig a little deeper into 
details.  It may be that after discussion, we decide we have to 
undeprecate the events, but I'd like to be a little more certain that's 
necessary.


[1] http://www.schepers.cc/w3c/events/DOMActivate.html

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

Received on Thursday, 23 July 2009 12:56:55 UTC