[whatwg] autocompletetype vs autocomplete, type attributes

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!


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 :)

-- 
regards, Kornel Lesi?ski

Received on Thursday, 26 January 2012 16:23:49 UTC