- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 15 Jun 2010 11:31:11 -0700
- To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
- Cc: public-forms@w3.org, public-forms-request@w3.org, "support xsltforms" <xsltforms-support@lists.sourceforge.net>
- Message-ID: <OFDCC2B76B.FFC9E85C-ON88257743.0064B4B8-88257743.0065BB59@ca.ibm.com>
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 Blog RSS feed: 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 -----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 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 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.
Received on Tuesday, 15 June 2010 18:31:59 UTC