[whatwg] autocompletetype vs autocomplete, type attributes
isherman at chromium.org
Mon Feb 6 15:50:23 PST 2012
On Thu, Jan 26, 2012 at 4:23 PM, Kornel Lesiński <kornel at geekhood.net>wrote:
> On Thu, 26 Jan 2012 22:59:49 -0000, Ilya Sherman <isherman at chromium.org>
> 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
>> more fine-grained type information. My concern with <input type="tel
>> is that the user agent now has to parse the type attribute in two
>> 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?
> You have a good point. If UA is supposed to choose first type it
> understands, then "tel fax" wouldn't work as a fax field, but "fax tel"
> would. That's a nasty gotcha, so a selection algorithm should be more
> sophisticated than that.
> <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.
> That's great!
Since I saw no objections, I've gone ahead and made this update. The
wording could probably use some editing/tweaking -- feel free to nitpick,
and to edit away nits if you have a wiki account with suitable permissions
> If I may bikeshed a bit more: since HTML5 uses "tel", then
> autocomplete[type] should use word "tel" too (instead of "phone") — just to
> be consistent and use same name for the same thing.
> Order of words in cc-full-name is inconsistent with name-full.
> hCard uses "given-name" and "family-name", while current autocomplete
> proposal has same "given-name", but uses "surname". It would be nice to
> rename autocomplete types for consistency with hCard where possible (unless
> they're consistent already with something else I don't know :)
Indeed. I've gone ahead and updated all the token names to match hCard
where possible. Let me know if you spot any others that are amiss.
> regards, Kornel Lesiński
More information about the whatwg