RE: Input bound to boolean node and incremental

Leigh,

We should be careful that we don't lose the 'device independency' by specifying how a control exactly behaves. Therefore I think that we should be really careful when changing wording related to when data must/should be committed/events must/should be dispatched. I don't say that we don't need to change/add something by definition, but we should do it with a lot of care/thought.

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 <mailto:nick.van.den.bleeken@inventivegroup.com>
http://www.inventivedesigners.com<http://www.inventivedesigners.com/>
Linked in<http://be.linkedin.com/in/nvdbleek>

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of Klotz, Leigh
Sent: dinsdag 15 juni 2010 20:42
To: John Boyer
Cc: public-forms@w3.org; public-forms-request@w3.org; support xsltforms
Subject: 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
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.


--
This message has been scanned for viruses and
dangerous content, 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.
--