This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13602 - autoassist attribute for input element
Summary: autoassist attribute for input element
Status: RESOLVED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2011-08-03 11:24 UTC by Cameron Jones
Modified: 2011-09-25 01:02 UTC (History)
8 users (show)

See Also:


Attachments

Description Cameron Jones 2011-08-03 11:24:07 UTC
The input elements will benefit from the addition of a new attribute called 'autoassist' for authors to register that the UA should automatically provide assistance in the completion of the input field.

This differs from the functionality of 'autocomplete' which instructs the UA to automatically pre-fill the input field with previously entered values.

Example 1: The 'file' input type currently brings up a system-level modal dialog for selecting an input file when it is given UI focus. This behavior eliminates the possibility for a user to manually enter an absolute file location without having to dismiss a modal dialog. This would be eliminated by setting autoassist="off" which would disable any automatic popup of such assistance.

Example 2: The 'email' and 'tel' input types represent items of contact information that the UA may have a corpus of data available from which to assist the user in filling out these fields. The HTML page author may declare they want the UA to assist the user in filling out these fields by providing a selection UI from which the user may choose a known value, or enter a new value.

It is expected that other input types will also benefit from the inclusion of this attribute and that browsers are allowed to provide disparate implementations at a level of differentiation in the interests of their users.

This source of this bug was discussion in the following thread:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032645.html
Comment 1 Anne 2011-08-03 13:14:27 UTC
I do not see the connection with that email. I also do not think this is something we should add since UI of form controls is up to user agents.
Comment 2 Cameron Jones 2011-08-03 14:08:02 UTC
>> I do not see the connection with that email.

The email thread seems a bit mixed up through July-August months, here is the correct order for referenced mails:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032645.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032647.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-August/032772.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-August/032785.html


>> I also do not think this is something we should add since UI of form controls is up to user agents.

This does not alter the UI of form controls but adds an additional user-specification for the UA to assist the user in their interaction with form controls.

This allows for browsers to provide richer UI for their users and is unrestricted allowing for any potential implementation and integration level, including none at all.

In addition, it allows for currently flawed UI implementations to be rendered inactive by page authors.
Comment 3 Anne 2011-08-03 14:12:36 UTC
If UI in implementations is flawed it would need to be fixed. You do not fix bugs in implementations by introducing new features to work around them.
Comment 4 Cameron Jones 2011-08-03 14:20:03 UTC
It is the HCI mode of operation and lack of customization which is the flaw, and that which this bug and additional attribute seek to fix.
Comment 5 Kornel Lesinski 2011-08-03 19:36:02 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. 

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

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.
Comment 6 Michael[tm] Smith 2011-08-04 05:13:26 UTC
mass-move component to LC1
Comment 7 Cameron Jones 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.
Comment 8 Kornel Lesinski 2011-08-04 23:03:50 UTC
> 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.

I think you're wrongly assuming that assistance and ability to type new value are mutually exclusive. 

For example date and e-mail controls in Opera provide assistance (calendar pop-up, addressbook autocompletion), but still allow user to type any valid value (including e-mail addresses that are not in the address book).

Even if tel control pops up contacts picker by default, UA could have option like "Add new number&#8230;" in the picker somewhere.

Safari doesn't have editable text field in <input type=file>, but advanced users are still able to type path manually. And there is no risk that page autor will enable text path entry and confuse who don't know what file path looks like.

How those controls work should be up to UA as long as user is able to enter any value.
Comment 9 Cameron Jones 2011-08-05 16:14:24 UTC
Bug withdrawn.

The inclusion of this attribute would impose assumptions on the UI implementation of a UA. 

The ability for a UA to define system integration and interfaces is of greater importance than the ability for an author to declare the mode of operation of such interfaces.

Any UA issues will be raised directly.