RE: Deprecating DOMFocusIn/DOMFocusOut


Hi Doug,

Please correct me if I'm wrong. But isn't it the case that :

  - A double click results in multiple click (and also mousedown and mouseup) events, but results in one DOMActivate element with a context info of detail equal to 2.


  - XForms depends on both DOM Events and XML Events and explictly refers to a number of the events defined in DOM Events which must be implemented by an XForms implementation. This ensures full compatibility with host langagues that also use DOM Events, and prevents the needless 'dispatching' of simular events (sometimes the only difference beeing the name if 'focusin' and 'focusout' are introduced) if the same events are used by the host language. Having the same events in the host language and XForms has the additional benefit of a better integration they can be handled, propagation stopped, or canceled in the host language in the same way as if they've been dispatched to native host language controls(having two simular events has the additional disatvantage of having a capture original event, default action original, capture abstract event, default action abstract event, bubble abstract event, bubble original event which can be a problem in certain cases). I also personally don't see what is won with depricating events in a spec that are used by other dependant specs. I know that the dependant specs can re-introduce the events again in there spec as not beeing depricated if they really want to, but I think this would be bad from a design point of view. Additionally I personally think we can't affort us of removing those events from the XForms spec, because they are widely used in XForms documents today (DOMActivate even in almost every document).


Regards,


Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
Nick_Van_den_Bleeken@inventivegroup.com
http://www.inventivegroup.com


> -----Original Message-----
> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
> On Behalf Of Doug Schepers
> Sent: donderdag 23 juli 2009 14:57
> To: www-dom@w3.org
> Cc: public-forms@w3.org
> Subject: 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
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
>


Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--

Received on Thursday, 23 July 2009 15:08:14 UTC