[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification

On Fri, Jan 20, 2012 at 2:02 AM, Simon Pieters <simonp at opera.com> wrote:

> On Thu, 19 Jan 2012 06:30:08 +0100, Ilya Sherman <isherman at chromium.org>
> wrote:
>
>> On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman <isherman at chromium.org>
>> wrote:
>>
>>> Current autofill products rely on contextual clues to determine the type
>>> of data that should be filled into form elements. Examples of these
>>> contextual clues include the name of the input element, the text
>>> surrounding it, and placeholder text.
>>>
>>> We have discussed the shortcomings of these ad hoc approaches with
>>> developers of several autofill products, and all have been interested in
>>> a
>>> solution that would let website authors classify their form fields
>>> themselves. While current methods of field classification work in
>>> general,
>>> for many cases they are unreliable or ambiguous due to the many
>>> variations
>>> and conventions used by web developers when creating their forms:
>>>
>>>  + Ambiguity: Fields named "name" can mean a variety of things, including
>>> given name, surname, full name, username, or others. Similar confusion
>>> can
>>> occur among other fields, such as email address and street address.
>>>
>>>  + Internationalization: Recognizing field names and context clues for
>>> all the world?s languages is impractical, time-intensive, and error-prone
>>> (as good context clues in one language may mean something else in another
>>> language)
>>>
>>>  + Unrelated Naming: Due to backend requirements (such as a framework
>>> that a developer is working within), developers may be constrained in
>>> what
>>> they can name their fields. As such, the name of a field may be unrelated
>>> from the data it contains.
>>>
>>>
>>> We believe that website authors have strong incentive to facilitate
>>> autofill on their forms to help convert users in purchase and
>>> registration
>>> flows. Additionally, this assists users by streamlining their experience.
>>>
>>> To that end we would like to propose adding an autocompletetype attribute
>>> [1] to the HTML5 specification, as a complement to the existing
>>> autocomplete attribute that would eliminate ambiguity from the process of
>>> determining input data types.  We developed this initial draft proposal
>>> working together with developers or several autofill products, and are
>>> now
>>> looking forward to feedback and suggestions from the broader community.
>>> [1] http://wiki.whatwg.org/wiki/**Autocompletetype<http://wiki.whatwg.org/wiki/Autocompletetype>
>>>
>>> Thanks,
>>> ~Ilya Sherman, Chromium Autofill Developer
>>>
>>>
>> I have gotten a bit of feedback about this proposal via email/IRC/Google+;
>> but this thread has been vewy vewy quiet.  On Google+, Tantek ?elik
>> expressed concern [1] that this proposal ?appears to be a fait-accompli,
>> that is, having already been implemented? in Chrome 15 under the
>> experimental attribute x-autocompletetype.  As I explained in my response
>> to Tantek's post, this proposal is not intended as a fait-accompli; but
>> rather is very much open to feedback and iteration.  If you have any
>> comments or suggestions, please send them along!  We have no interest in
>> indefinitely supporting this attribute prefixed with "x-", and fully
>> expect
>> the proposal to evolve prior to (hopefully) acceptance into the HTML
>> specification.
>> [1] https://plus.sandbox.google.**com/114128403856330399812/**
>> posts/9dKsD7Mi7JU<https://plus.sandbox.google.com/114128403856330399812/posts/9dKsD7Mi7JU>
>>
>
> Maybe some of the supported keywords could be dropped (e.g. those that are
> not recommended to use). Since there's no legacy yet, we can reject bad
> keywords completely and only support the best practice keywords. Similarly,
> there's address-line1, address-line2 and address-line3 -- maybe they could
> be dropped and encourage authors to use a textarea for address?
>

Dropping the discouraged keywords (e.g. "phone-local-prefix") certainly
seems reasonable to me, in the interest of keeping the predefined token set
relatively small.  On the other hand, these seven discouraged keywords were
added to the initial proposal because a nontrivial number of existing forms
currently structure their fields in this way.  I'd love to get more
people's insights into this tradeoff.  I'll go ahead and fork off a thread
specifically for discussion of the specific choice of tokens, so that this
thread can remain focused on the more high-level details of the proposal.

For the address lines, I don't think it's practical to encourage authors to
use a textarea rather than separate fields.  To the best of my knowledge,
almost no website currently uses textareas for this purpose, so textareas
are only a theoretical best practice -- users and developers both tend to
expect the address lines to be separate fields.  Moreover, transitioning
from separate fields to a single textarea would require backend migrations
(in the parsing code, the database, or both) in order to store the data
entered in this new format.  That would negate one of the key advantages of
this proposal, i.e. the lack of need for backend migrations, relative to
ECML.

The extensibility story should maybe use the wiki registration style like
> <link rel> keywords.
>

Sorry, I'm not quite following what you mean by this.  If you have a wiki
account and would like to make this improvement, please go for it :)


> The proposal states:
>
> "The main drawback to this solution is that unless approved as a part of
> the HTML specification, a website that implements the autocompletetype
> attribute would not be valid HTML."
>
> This is not technically correct. The HTML spec has the "other applicable
> specifications" extensibility point.


Fair enough -- thanks for pointing that out.  Updated the text to more
specifically focus on existing HTML validators, which likely would not
parse the autocompletetype attribute as valid HTML without the attribute's
acceptance into the HTML5 specification.


> --
> Simon Pieters
> Opera Software
>

Received on Friday, 20 January 2012 15:28:25 UTC