On Thu, 26 Jan 2012 08:38:41 -0000, 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=off><input 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
