Re: Allow xf:setfocus with no @control to set the focus to the event target

Hi Mark,

I'd like to understand whether the example of keeping the focus on a 
control if it is filled out incorrectly really works as a technique. 

One problem is that filling out one field incorrectly may cause multiple 
controls to receive xforms-invalid events, and they will arrive in an 
undefined order, so there is no way to guarantee that the focus will stay 
in "the" invalid control.  Could work for simple forms with few data 
dependencies, but is not generally applicable.

A second problem is that the invalidity in one control may be the fault of 
a bad data entered elsewhere.  The user may want to leave the invalid data 
but then go fix the real problem.  For example, suppose the user with a 
bachelor's degree is asked to enter his age and he types 18 rather than 
28.  A simple typo.  Then, when asked for years of schooling, the user 
enters 20.  This pops a constraint because he can't have more years of 
education than he has years of life.  However, the problem is with the age 
data, not the education data. 

For the above reason, and just generally speaking, it is usually 
considered to be poor UX to freeze up the focus in an invalid control. The 
better practice is to stop the first focus out, but then let the second 
attempt to remove focus succeed if the user has made no changes.  Now it 
turns out that a quirk of our processing model might actually make an 
"event target setfocus" do exactly this behavior because a second tab 
would not change the value, so you would not get another invalid event. To 
be clear, if you have this

<input ref="age" id="X">
   <label>Age</label>
   <setfocus ev:event="xforms-invalid" control="X"/>
  <alert>Please enter an integer number.</alert>
</input>

then if the user types "abc" and hits tab, then the focus would stay in 
the control and the user would see the alert.  But if the user hits tab 
again, then no data has changed so I don't think another xforms-invalid 
event would occur, which means the focus would move on, right?

If so, is this the same as "preventing the user from leaving the control 
if its value is not set appropriately"? 

And regardless of how this discussion goes, I don't really understand why 
using the event function would look weird. 

<setfocus ev:event="xforms-invalid">
     <control value="event('target')"/>
</setfocus>

It seems to say enough that it is clear what is going on.  Put another 
way, even if we chose a default of event target, I don't think the method 
is declarative until you have a way to explicitly state the default, so it 
would still be necessary to have a way of saying that the control to focus 
is given by the event target.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
"Mark Birbeck" <mark.birbeck@webbackplane.com>
To:
John Boyer/CanWest/IBM@IBMCA
Cc:
"Ulrich Nicolas Lissé" <unl@dreamlab.net>, public-forms 
<public-forms@w3.org>
Date:
08/20/2008 06:56 PM
Subject:
Re: Allow xf:setfocus with no @control to set the focus to the event 
target




Hi John,

> [snip]
>
> Does it really make sense to try to focus the event target?

If that's what the author wants...yes. It's not uncommon in HTML forms
to prevent users from leaving a control if its value is not set
appropriately, for example.


>  What if a
> sequence of actions is grouped together and invoked from multiple 
locations
> using dispatch?

Sure...but if the listener is on the control, then you'll always
ultimately get Event.target set to the control in question, won't you?


> It seems an odd thing to see <setfocus/> without any indication of what 
the
> focus is being set to.

No different to any other default values, surely? (xf:rebuild,
xf:refresh, xf:submit, xf:send, etc.) And a lot less weird looking
than using the event() function. :)

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)