<CAA3nRaj2EKfzw19bXxOeWJ+LyHSty4sZRBF53-paCM_zXo07-w@mail.gmail.com>
Current votes: None.
On Thu, Jan 26, 2012 at 4:23 PM, Kornel Lesi=C5=84ski <kornel@geekhood.net>= wrote: > On Thu, 26 Jan 2012 22:59:49 -0000, Ilya Sherman <isherman@chromium.org> > wrote: > > Ah, I had thought you were suggesting that simply <input type=3D"fax"> >> should be valid, and should behave just as <input type=3D"tel"> does, ex= cept >> with >> more fine-grained type information. My concern with <input type=3D"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 "te= l" >> as the relevant token; but (ii) for autofill, the user agent should pars= e >> "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=3D"fax tel"> be parsed? What should hap= pen >> if the markup simply says <input type=3D"fax">? What about <input type= =3D"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=3Doff> <input autocomplete=3Demail> >>> >>> In case of <form autocomplete=3Doff><input autocomplete=3Demail></form>= I'd >>> expect autocomplete=3Demail 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=3D"text" autocomplete=3D"bogus"> -- and henc= e also >> <input type=3D"text" autocomplete=3D"email"> -- to be equivalent to <inp= ut >> type=3D"text" autocomplete=3D"off">. However, I just checked with IE, C= hrome, >> Firefox, Safari, and Opera -- all simply ignore autocomplete=3D"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") =E2=80= =94 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 (unle= ss > 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=C5=84ski >