[whatwg] autocompletetype vs autocomplete, type attributes

[Kornel Lesiński]

On Thu, 26 Jan 2012 08:38:41 -0000, Ilya Sherman <isherman at chromium.org>  
wrote:

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

Orthogonality of validation and autofill sounds nice, but is it useful in  
practice?

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


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


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