Re: [whatwg] autocompletetype vs autocomplete, type attributes
(Note that the main thread for this discussion is here: [ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-January/034429.html].) On Wed, Jan 25, 2012 at 12:03 PM, Kornel Lesiński kor...@geekhood.netwrote: Google's annoucement of autocompletetype type[1] uses type=text field for e-mail input, which doesn't seem right given that HTML has input type=email already. Yes, this was a poor choice of example, sorry. Imagine that the example was address line 1 instead :) Should input type=text autocompletetype=email behave just like input type=email? Similar ambiguity exists for input type=text autocompletetype=phone-full and input type=tel. 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. 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.? Why not fold autocompletetype types into the existing type attribute (or autocomplete attribute)? Type could be redefined as space-separated list, so input type=cc-full-name name-full section-billing could work just like autocompletetype. It would be backwards compatible with HTML5 types and fall back to text for new types or lists. I've commented on this suggestion in the other thread (Proposal for autocompletetype Attribute in HTML5 Specification, linked to above). 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. 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. [1] http://googlewebmastercentral.**blogspot.com/2012/01/making-** form-filling-faster-easier-**and.htmlhttp://googlewebmastercentral.blogspot.com/2012/01/making-form-filling-faster-easier-and.html -- regards, Kornel Lesiński
Re: [whatwg] autocompletetype vs autocomplete, type attributes
On Thu, 26 Jan 2012 08:38:41 -, Ilya Sherman isher...@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? 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. 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 (my expected rendering for this field would be [ are you serious? fax in the 21st century!? ] ;) 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=offinput autocomplete=email/form I'd expect autocomplete=email to override form's off value. 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
Re: [whatwg] autocompletetype vs autocomplete, type attributes
On Thu, Jan 26, 2012 at 5:03 AM, Kornel Lesiński kor...@geekhood.netwrote: On Thu, 26 Jan 2012 08:38:41 -, Ilya Sherman isher...@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=offinput 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
Re: [whatwg] autocompletetype vs autocomplete, type attributes
On Thu, 26 Jan 2012 22:59:49 -, Ilya Sherman isher...@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=offinput 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
Re: [whatwg] autocompletetype vs autocomplete, type attributes
Google's annoucement of autocompletetype type[1] uses type=text field for e-mail input, which doesn't seem right given that HTML has input type=email already. Should input type=text autocompletetype=email behave just like input type=email? Similar ambiguity exists for input type=text autocompletetype=phone-full and input type=tel. Why not fold autocompletetype types into the existing type attribute (or autocomplete attribute)? Type could be redefined as space-separated list, so input type=cc-full-name name-full section-billing could work just like autocompletetype. It would be backwards compatible with HTML5 types and fall back to text for new types or lists. Having all of type, autocomplete and autocompletetype looks quite messy. [1] http://googlewebmastercentral.blogspot.com/2012/01/making-form-filling-faster-easier-and.html -- regards, Kornel Lesiński
