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

[whatwg] autocompletetype vs autocomplete, type attributes

From: Ilya Sherman <isherman@chromium.org>
Date: Thu, 26 Jan 2012 00:38:41 -0800
Message-ID: <CAA3nRajFoGoofJv9joH7nEi0k0x_t-L==2PGNmtheD67iSo=bg@mail.gmail.com>
(Note that the main thread for this discussion is here: [
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-January/034429.html].)

On Wed, Jan 25, 2012 at 12:03 PM, Kornel Lesi?ski <kornel at geekhood.net>wrote:

>
> Google's annoucement of autocompletetype type[1] uses type="text" field
> for e-mail input, which doesn't seem right given that HTML has <input
> type="email"> already.
>

Yes, this was a poor choice of example, sorry.  Imagine that the example
was "address line 1" instead :)


> Should <input type="text" autocompletetype="email"> behave just like
> <input type="email">? Similar ambiguity exists for <input type=text
> autocompletetype=phone-full> and <input type=tel>.
>

IMO, the autocompletetype attribute should have no effect on the
rendering/formatting of the form field, whereas the type attribute should.
 So, user agents might validate the format of data entered into an <input
type="email"> field, but should not try to perform similar validation for
an <input type="text" autocompletetype="email"> field.

<input type="tel"> is actually a little more subtle, in that it is
ambiguous between what type of phone number is expected: a regular phone
number, a fax number, etc.?


> Why not fold autocompletetype types into the existing type attribute (or
> autocomplete attribute)? Type could be redefined as space-separated list,
> so <input type="cc-full-name name-full section-billing"> could work just
> like autocompletetype. It would be backwards compatible with HTML5 types
> and fall back to text for new types or lists.
>

I've commented on this suggestion in the other thread ("Proposal for
autocompletetype Attribute in HTML5 Specification", linked to above).
 Briefly, I think the type attribute is designed to describe slightly
broader types, just detailed enough to enable user agents to properly
render or format or validate form fields and their data.  The
autocompletetype attribute, on the other hand, tries to achieve a higher
level of precision.  I anticipate that merging these two use cases into a
single attribute is undesirable, but I'd love to hear from those more
deeply familiar with the design decisions behind the type attribute.


> Having all of type, autocomplete and autocompletetype looks quite messy.
>

One small saving grace here: Since autocomplete defaults to "on", it should
be rare to need to specify both autocomplete and autocompletetype.


> [1] http://googlewebmastercentral.**blogspot.com/2012/01/making-**
> form-filling-faster-easier-**and.html<http://googlewebmastercentral.blogspot.com/2012/01/making-form-filling-faster-easier-and.html>
>
> --
> regards, Kornel Lesi?ski
>
Received on Thursday, 26 January 2012 00:38:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC