[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification

[John Tamplin]

On Fri, Jan 20, 2012 at 6:28 PM, Ilya Sherman <isherman at chromium.org> wrote:

> > 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.


I don't see how requiring forms to lump the address together is going to
help -- if the database stores the fields separately, other APIs that the
backend needs to give the address to (such as shipping carriers, address
cleanup/geocoding, etc) expects separate fields then all you are doing is
pushing the parsing of the address off to the backend rather than letting
the user see it.  Also, I think a properly localized (ie, fields dependent
on the country given) address form is much more likely to get the correct
data from the user than just asking them to enter a blob of text.

One question -- how does this fit with, say, a <select> element for country
that shows localized country names?  Can it be "autocompleted" as well?  If
so, does it match on the localized names, the value (which might be an ISO
2 or 3-digit code, or something unique to the app), or what?

-- 
John A. Tamplin
Software Engineer (GWT), Google