- From: Ilya Sherman <isherman@chromium.org>
- Date: Wed, 15 Feb 2012 16:33:39 -0800
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