[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification

On Thu, Jan 26, 2012 at 12:15 AM, Ilya Sherman <isherman at chromium.org>wrote:

> Extending the existing input 'type' attribute is an interesting idea,
> thanks for raising it.  Looking through the existing input type values, it
> seems they are primarily chosen so as to enable user agents to render and
> format the input data in type-appropriate ways.  However, the existing
> types do not try to nail down the field's exact data type beyond the needs
> of this use case -- for example, <input type='tel'> currently covers both
> phone and fax fields.  In contrast, for many autocomplete/autofill agents,
> the distinction between phone and fax fields is important.


I think of the distinction here as follows:

Imagine the various values forms might want.  For example, first name, last
name, home address, work address, home phone, mobile phone, fax.

Now classify these by kind.  (For an object-oriented programmer like me,
this would be "enumerate the different classes/types required to hold the
above values".)  You might come up with "name", "address", "phone number".
 All phone numbers share some set of properties, such as consisting of
digits, as do all names, all addresses, etc.

The distinction between what kind of a value something is and what precise
instance of that kind it is is a valuable distinction.  As you noted
already, the former can be used to do structural validation or provide
helpful UI for entry without needing to understand the latter.

I see "type" versus "autocompletetype" in this same way.  "type" allows the
UA to understand the structure of a form value while "autocompletetype"
allows it to understand which particular values might commonly go there.
 Certainly we could eliminate the former and just use the latter, but there
is a major downside.

Imagine my UA has support for all the above example specific types I gave.
 Now a web author wants to write a form with a new value, e.g. "maiden
name" or "pager number".  It would be wrong to use any of the above
autocompletetype values, since this field doesn't mean any of those things.
 But that means I can't get the UA to do validation or UI assistance for me
either.

We could try to solve this by allowing our unified "type" attribute to take
on the union of all "type" and "autocompletetype" values.  But this is
confusing.  When I can have type "phone number" or "home phone number",
which do I use?  It's not necessarily clear to a web author what the
practical ramifications of this choice are.

Therefore, I think leaving these fields separate makes sense even if
sometimes one could imply the "type" from the "autocompletetype".

PK

Received on Thursday, 26 January 2012 11:13:22 UTC