[whatwg] autocompletetype vs autocomplete, type attributes
kornel at geekhood.net
Thu Jan 26 05:03:42 PST 2012
On Thu, 26 Jan 2012 08:38:41 -0000, Ilya Sherman <isherman at chromium.org>
> IMO, the autocompletetype attribute should have no effect on the
> rendering/formatting of the form field, whereas the type attribute
> 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.
Orthogonality of validation and autofill sounds nice, but is it useful in
The only use case I can think of for a field autocompleted like an e-mail
field, but not validated like an e-mail field would be login form with a
username field that accepts either username or e-mail.
However, login forms are better served by login-specific autofill that is
in current browsers (saving opaque login field and password field
together), since you don't want to enter arbitrary e-mail address from
your addressbook, but a specific e-mail/login and a matching password at
the same time.
Are there any other cases where you'd like field that is autocompleted,
but doesn't otherwise behave like the autocompleted type?
But even if single-mixed-login-field autocomplete was desired, then
perhaps a mixed type would work too:
<input type="username email">
It could be defined to mean that either of the two types is accepted, and
autocomplete works for both.
Also orthogonal type and autocompletetype allows nonsense combinations
like <input type=number autocompletetype=email>, while a precise type
attribute would ensure that rendering and autocomplete always make sense
> <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.?
Which is why I've suggested extending type attribute to take a token list:
<input type="tel fax">
(my expected rendering for this field would be "[ are you serious? fax in
the 21st century!? ]" ;)
> 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.
In the thread you've pointed to I saw suggestion to make registration of
new types open for anybody, and that could cause difficulty introducing
new kids of validation/UI under names formerly used only for autocomplete.
How about merging autocompletetype with autocomplete then?
It looks sensible to me:
<input autocomplete=off> <input autocomplete=email>
In case of <form autocomplete=off><input autocomplete=email></form> I'd
expect autocomplete=email to override form's "off" value.
>> 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.
I can't imagine usefulness of this:
<input autocomplete=off autocompletetype=email>
and if that case is left out, then I don't see a reason to keep both
I really like the idea of more specific autocomplete types and use of list
of tokens for this, but the proposed attribute in its current form is
overlapping/conflicting with existing attributes, and even the name
'autocompletetype' itself gives me an impression of a forced extension,
rather than integral part of the language.
regards, Kornel Lesiński
More information about the whatwg