RE: Input bound to boolean node and incremental

This comes up often and we fix it in different ways, without ever saying what we'd like to say.  I recall it was the Mozilla XForms implementation that didn't commit select1 until you tabbed off, and we fixed that with the @incremental='true' default on select1.
But we don't offer any hook in the spec to hang this suggestion.
 
I believe that in XHTML+XForms, it's important make checkbox act like select1: when you actuate it, it changes the value, and it sounds like you agree that's allowed by the spec.
 
Unfortunately, with the reading we've got now, that guidance is in the blank space after the period in this sentence: 
    When the form control is interactively changed and does not have the incremental="true" setting, no events are required to be dispatched, and thus no order is defined.
 
I think we need to offer a little more help to XForms processor implementors.
 
If so, should that go into the upcoming XHTML+XForms integration, where we are free to mention checkboxes, or is there a way we can add a note or a sentence to the XForms 1.1 Rec to make it clearer that it's desirable to have actuatable form controls issue xforms-value-changed more frequently?
 
Leigh.

 
________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Tuesday, June 15, 2010 11:31 AM
To: Klotz, Leigh
Cc: public-forms@w3.org; public-forms-request@w3.org; support xsltforms
Subject: RE: Input bound to boolean node and incremental



Hi Leigh, 

Actually, the wording in Section 4.6.1 is *very* carefully chosen to permit the UI control implementation to decide how incremental="false" is handled. 
When not set to incremental="true", events are not required to be dispatched, which is different from saying that events are not dispatched. 

This means that the xsltforms implementation may technically be within spec, but it is also plain that once a specific UI control is mapped to an abstract control like xf:input, the UI controls should behave according to commonly known UX expectations for that kind of control. 

So, I think it would reasonable to say that xf:input mapped to input should set the data node value when the checkbox is clicked.  This would also be in accord with saying that the user has "activated" the control by clicking on it or using the keyboard selection mechanism (usually the space bar). This means of activation recognizes that a checkbox is a "button-esque" kind of xf:input.  By comparison, a single line textual input control can be also be "activated" by hitting enter within it, and the value will change without the input control losing the focus or having the user navigate away from it. 

Cheers, 
John M. Boyer, Ph.D.
IBM Distinguished Engineer, Interactive Web Applications and Documents 
IBM Lotus Forms Architect
Workplace, Portal and Collaboration Software
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com  

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





From: 	"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
To: 	<public-forms@w3.org> 
Cc: 	"support xsltforms" <xsltforms-support@lists.sourceforge.net> 
Date: 	06/15/2010 10:43 AM 
Subject: 	RE: Input bound to boolean node and incremental

________________________________




Test case: http://xformstest.org/klotz/2010/06/input-boolean-incremental/test.xml <http://xformstest.org/klotz/2010/06/input-boolean-incremental/test.xml>  

-----Original Message-----
From: Klotz, Leigh 
Sent: Tuesday, June 15, 2010 10:26 AM
To: public-forms@w3.org
Cc: support xsltforms
Subject: Input bound to boolean node and incremental

According to
http://www.w3.org/TR/xforms11/#sequence-for-input <http://www.w3.org/TR/xforms11/#sequence-for-input> 

xf:input change the value until you navigate off, unless you use incremental="true".

If the bound node is of type xsd:boolean, however, most desktop browser XForms processors will render the control as a checkbox.
So, if you check the checkbox, nothing happens until you navigate off.

I've not seen implementations with the behavior that checkboxes don't work until you tab off before, but now xsltforms is exhibiting it.
A quick read of the XForms 1.1 Rec shows that it may be the spec-correct behavior.

We had a similar situation with select1, and we fixed it by saying that the default value of attribute incremental for select1 is true:

http://www.w3.org/TR/xforms11/#sequence-for-select1 <http://www.w3.org/TR/xforms11/#sequence-for-select1> 

How can we fix it for input bound to boolean?  It doesn't seem like we can easily say that the default value of attribute incremental for input bound to boolean is true.

Authors might not know whether a control is bound to a boolean or not; for example, now that we allow non-homogeneous repeats:
 <repeat nodeset="*"><input ref="value"><label ref="../label"></label></input>

Leigh.