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

Schalk Neethling schalk at ossreleasefeed.com
Thu May 6 04:35:25 PDT 2010


Your suggestion sounds really interesting Thomas, I will have a read over it. I agree that if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address.

If that was a problem, it would have been detected during registration.

Schalk Neethling

-----Original Message-----
From: Thomas Broyer [mailto:t.broyer at gmail.com] 
Sent: Thursday, May 06, 2010 12:09 PM
To: Markus Ernst
Cc: Schalk Neethling; WHATWG List; Steve Dennis
Subject: Re: [whatwg] RFC: <input type="username">

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/




More information about the whatwg mailing list