[Bug 13602] autoassist attribute for input element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13602

--- Comment #7 from Cameron Jones <cmhjones@gmail.com> 2011-08-04 14:43:26 UTC ---

> 1. File selection dialogs can allow user to enter path (e.g. Mac OS X does that if you type "/"). I don't think that disabling any other way of input is the right way of enabling direct path input. 

The feature is not for disabling any way of providing input, it is for
specifying whether the UA should automatically provide assistance to the user
or not.

The file picker represents a form of assistance to the user over direct text
entry within a text field. It provides a graphical representation of the
accessible filesystems to assist the user in selecting the appropriate file.

There is no specification for how a UA should implement the UI of form
controls. There is however the effective implementation incumbency for
accessibility, compatibility and legacy reasons that inputs provide and default
back to a text field for capturing their value.

The implementation of the file input control has been to provide a text field
and an "assistance" button for launching the file picker. 

The default behavior has been to activate this assistance on focus. If the
field itself were uneditable this would be acceptable, however it is bad
human-computer-interaction and user interface design to force this behavior on
all users indiscriminately. 

This scenario is encountered because there is no means of specifying if this
assistance should be given by default or not, the inclusion of this new
attribute provides such a means of specification.

> Besides, direct path input has been deliberately removed from Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=258875

This is an old bug and reading through the comments the mozilla team struggled
with these HCI issues, specifically:

"The important part is that a file picker is not popped up if you tab through a
form containing an <input type=file>"

However this seems to be the only resolution of this bug, the original
functionality from ff1.x, and seen in all other browsers, remains.

> 2. UAs allow user to enter new values in email and tel type, so I'm not sure if I understand the problem. In case of e-mail and tel types one way of
"disabling" assistance is to use type=text instead.

I should have provided these examples in the reverse order as it is this
example which illustrates the nature of the enhancement.

Micheal Hanson from mozilla provided an implementation story from their
Contacts API work which described how they are providing assistance to form
users when filling out fields which may be available within an address book -
email and telephone numbers. 

The UI for this may be seen to be similar to that of file pickers - although in
this case we're looking at "email pickers" and "telephone pickers". 

It must be accepted that text-field entry is essential for these input types,
users will always find it easier to just type a known email address or
telephone number, but in the case of wanting to enter the address of a friend
they may prefer some kind of customized assistance which may directly hook into
local or networked address book and contact details.

So, there exists a need for text-field input entry. There also exists a need
for integration with non-page resources for value restriction and integrity
guarantees. There also exists a need for richer UIs and their declaration for
use by page authors.

These factors add together to provide a compelling reason for the inclusion of
a new property to inputs for the specification, or omission of, a rich and
integrated UI for the user to be assisted in their task of completing form
fields.

The UI pattern which would is already the case for file inputs and which is a
potential solution for the new input types as well, is to provide a text field
and an associated assistance initiator.

As there are multiple methods of interacting with the input controls, the means
for the author to define the mode of interaction is valid. I would expect this
to be used in conjunction with setting the main text field to uneditable, as
the research from mozilla also concluded.

The additional use cases which i did not highlight initially might include:

* Auto-assistance in search input with previous searches
* Auto-assistance in date* inputs with calendar popup (spinner may also be
present within text field)
* Auto-assistance in color selection

Most all of the new input types require or will benefit from the addition of
rich assistive UIs. The means for controlling the interaction with these UI
controls requires specification.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 4 August 2011 14:43:31 UTC