[whatwg] RFC: <input type="username">

[Thomas Broyer]

On Thu, May 6, 2010 at 11:51 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Am 05.05.2010 23:06 schrieb Schalk Neethling:
>>
>> The way I see it is that instead of browsers traversing the DOM looking
>> for
>> an input field of either id=username or name=username or even
>> class=username, they now only have to look for an input of type username.
>> Makes it a lot easier for both developers and browser vendors as they now
>> only have to look for an input of type username and gives developers the
>> freedom to use any name, id or class.
>
> But in many cases the username is an e-mail address, then you get a conflict
> with type="email".

type=email is expected to (depending on the browser) allow you to
search into/autocomplete from your address book. I really don't see a
conflict here, it's not about syntax, it's about "semantics"
(otherwise, just use a pattern="" constraint).

But actually, I'm not convinced type=username is required (or even
useful). We're told that Cookies are bad for security and shouldn't be
used for authentication (or other sensible data), so spec'ing this in
HTML, which is expected to live for tens of years, would really be a
Bad Thing (tm).

It has been proposed earlier (a year and a half ago, at least) to
reconcile Cookie-based auth with HTTP-auth, and that could be a way to
tell the browser "which form" and/or "which fields" in the page are
related to login.
I posted a first draft of such a thing more than a year ago:
http://tools.ietf.org/html/draft-broyer-http-cookie-auth
I worked a bit on it since then to answer the feedback but I'm far
from an -01 draft (I'd like to rewrite it from scratch actually...)
http://github.com/tbroyer/http-cookie-auth

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/