- From: Aaron Reed <aaronr@us.ibm.com>
- Date: Mon, 20 Nov 2006 15:51:38 -0600
- To: John Boyer <boyerj@ca.ibm.com>
- Cc: "Klotz, Leigh" <Leigh.Klotz@xerox.com>, www-forms@w3.org, www-forms-editor@w3.org
- Message-ID: <OFF8FB3D32.4AD21AB8-ON8725722C.0074DC3C-8625722C.0077E0B7@us.ibm.com>
This approach will have some edge cases.
1) if there is a xforms-value-changed handler, then it will fire when the
user clicks on the dropdown toggle button but not when the user invokes the
dropdown using an accelerator key
2) value-change also wouldn't fire if input was being done using an
accessibility agent since the agent has access to the list of items w/o any
dropdowns.
3) no way for a user to start typing and then check whether other other
possible values might not be more appropriate w/o the xforms-value-change
firing.
4) using this approach, if I had a listbox combined with a texfield for
open user input (for example, for a xf:select w/ @appearance="open"), then
if the user started typing something and then clicked an item from the list
that met their answer better, then two xforms-value-changed events would
fire...one for the focus loss and one for the item selection. The new
selection might not even take place or worse yet, a different item ends up
being selected, if the xforms-value-changed handling changed the list out
from underneath the user.
To me, incremental="false" is as close as you can get to specifying 'wait
until the user is reasonably sure of their input before committing'. And
with any field that allows direct user input, I think that means 'wait
until another element is selected'.
But, of course, that is just my personal opinion.
--Aaron
IBM Corporation
Internal Zip: 9022D016
11501 Burnet Road
Austin, TX 78758
(512)838-9948
inet: aaronr@us.ibm.com
_
(} @
|= Volleyball Rules!!!
/\
John
Boyer/CanWest/IBM
@IBMCA To
"Klotz, Leigh"
11/16/2006 05:08 <Leigh.Klotz@xerox.com>, Aaron
AM Reed/Austin/IBM@IBMUS
cc
www-forms@w3.org,
www-forms-editor@w3.org
Subject
RE: Feed back on 1.0: Meaning of
incremental attribute(Document
link: Aaron Reed)
Hi Leigh and Aaron,
I missed the continuation of this thread.
The main value proposition for the default of incremental=true for
select/select1 is for selection="closed".
For selection="open", the default *should* be false. The problem is that
this cannot be expressed with schema, so I think we cannot change the
default to be false for selection="open" select/select1 controls.
However, if you say incremental="false" explicitly, then you should still
be able to use xforms-value-changed to add new items to the itemset for a
select/select1.
I understand from talking with Leigh that this caused problems because of
the belief that you have to "tab off" of the control in order to get the
xforms-value-changed.
However, I believe that you should also get the xforms-value-changed when
the user clicks the selection button on the control because the editable
part of the control is losing the focus, so the value should be commited to
the form data at that moment.
Cheers,
John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com http://www.ibm.com/software/
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
"Klotz, Leigh"
<Leigh.Klotz@xero
x.com> To
John Boyer/CanWest/IBM@IBMCA,
09/11/2006 09:47 <www-forms@w3.org>,
AM <www-forms-editor@w3.org>
cc
Subject
RE: Feed back on 1.0: Meaning of
incremental attribute
I would also like to have the meaning of incremental on select and select1
examined at the same time.
Aaron Reed pointed out to me that the default is true.
I believe we did this because we wanted the xforms-value-changed event to
change when the control itself was changed, and we have that description in
the text for select and select1.
If incremental is false, then only the select and deselect events are sent
until focus is lost.
Unfortunately, with select1/@selection='open', in a desktop browser, each
character you type in the entry field causes an xforms-value-changed.
That makes it difficult to capture the the value-changed event and use it
to add newly-typed values for the open enumeration into the itemset.
Leigh.
From: w3c-forms-request@w3.org [mailto:w3c-forms-request@w3.org] On Behalf
Of John Boyer
Sent: Monday, September 11, 2006 3:27 AM
To: www-forms@w3.org; www-forms-editor@w3.org
Subject: Feed back on 1.0: Meaning of incremental attribute
In Xforms 1.0, the description of the incremental attribute is inadequate.
It does not describe what it does really. It just says that when it is
true, more xforms-value-changed events will occur. Maybe that's the most
that can be said in general due to multimodality, but 1) it should then say
that additional events *may* occur, and 2) an example of a particular
modality should be given. I think that it could be described though that
incremental="true" means that each modification of the UI control by the
user is committed to data.
Also, the attribute should be described in one place and it should say that
it is optional with a default of false unless stated otherwise. Right now,
it is described over and over again for no reason other than that the
default is true sometimes (e.g. select1).
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com http://www.ibm.com/software/
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic26609.gif
- image/gif attachment: ecblank.gif
- image/gif attachment: doclink.gif
- image/gif attachment: pic05914.gif
Received on Tuesday, 21 November 2006 18:03:57 UTC