[whatwg] autocompletetype vs autocomplete, type attributes

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

Received on Monday, 6 February 2012 15:50:23 UTC