[whatwg] autocompletetype vs autocomplete, type attributes

[Ilya Sherman]

On Thu, Jan 26, 2012 at 5:03 AM, Kornel Lesiński <kornel at geekhood.net>wrote:

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

My comment was really meant in direct response to your question of "Should
<input type="text" autocompletetype="email"> behave just like <input
type="email">?"  Assuming type and autocompletetype remain separate
attributes, I would not expect the value of the autocompletetype attribute
to have any implications on rendering, formatting, or validation of the
corresponding field and its data -- so the two snippets of HTML you
provided should behave slightly differently.

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.


A space-separated type attribute likewise allows a nonsense combination
like <input type="number email">.  We considered creating a stricter
hierarchy of types that would disallow such nonsense.  However, (a)
developers could type the nonsense anyway, so we'd still have to specify
the error recovery mechanism; and (b) enforcing a hierarchy makes the
extensibility story much trickier.


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

Ah, I had thought you were suggesting that simply <input type="fax"> should
be valid, and should behave just as <input type="tel"> does, except with
more fine-grained type information.  My concern with <input type="tel fax">
is that the user agent now has to parse the type attribute in two different
ways: (i) For formatting and validation, the user agent should parse "tel"
as the relevant token; but (ii) for autofill, the user agent should parse
"fax" as the relevant token (and fall back to "tel" if "fax" is not
understood).  This gets really complex to describe and implement.  For
example, how should <input type="fax tel"> be parsed?  What should happen
if the markup simply says <input type="fax">?  What about <input type="tel
x-3D-fax fax"> and the various permutations of those tokens?


> (my expected rendering for this field would be "[ are you serious? fax in
> the 21st century!? ]" ;)


I rather agree :)  (A lot of websites do still have fax fields, though...)


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


I actually like this idea a lot.  We had previously chosen not to extend
the autocomplete attribute because we were worried about backward
compatibility.  In particular, we were worried that existing user agents
might interpret <input type="text" autocomplete="bogus"> -- and hence also
<input type="text" autocomplete="email"> -- to be equivalent to <input
type="text" autocomplete="off">.  However, I just checked with IE, Chrome,
Firefox, Safari, and Opera -- all simply ignore autocomplete="bogus".  So,
we seem to be ok in terms of backward compatibility -- hooray!

If I don't see any objections over the next few days, I'll go ahead and
update the proposal to extend the autocomplete attribute rather than
introducing the additional autocompletetype 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.
>>
>
> 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
>