W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification

From: Ilya Sherman <isherman@chromium.org>
Date: Wed, 15 Feb 2012 16:33:39 -0800
Message-ID: <CAA3nRaj4B2c+9QkEDKGemRRo_m+M3JiZGgkCLJd-XvNGBep6rA@mail.gmail.com>
On Wed, Feb 15, 2012 at 3:57 PM, Nathan Ziarek <nziarek at gmail.com> wrote:

> ...as I'm in the middle of a project implementing schema.org markup, is
> there any consideration of using those properties as the tokens within the
> autocomplete attribute?
>
> While not perfectly compatible, it would lessen the burden on
> developers?"Is it given-name or givenName for form fields?"


The current set of tokens was chosen to match the hCard [
http://microformats.org/wiki/hcard ] naming as much as possible.
 Unfortunately, it's not possible to match all of the major naming schemes
without bloating the token space with lots of redundant tokens.


> ?and schema.org's notion of scoping might prove a better solution than
> the section- nomenclature. After all, form elements already have a grouping
> element in <fieldset>.
>

We considered this, but realized that structural scope does not necessarily
match semantic scope for many existing web forms.  The most common reason
for this is using <table> elements to control layout :/


> In any case, I echo Jon's sentiment: looking forward to it!
>

:)

?
> nz
>
> On Feb 15, 2012, at 4:10 PM, Jon Honeycutt <jhoneycutt at apple.com> wrote:
>
> > I've shown this proposal to a couple of people here at Apple, and we
> have no issues with it. I'm personally eager to see it move forward!
> >
> > --
> > Jon
> >
> > On 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
> >>
> >> Thanks,
> >> ~Ilya Sherman, Chromium Autofill Developer
> >
>
Received on Wednesday, 15 February 2012 16:33:39 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC