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

[Thomas Broyer]

On Thu, May 6, 2010 at 12:12 PM, Mounir Lamouri wrote:
> On 05/06/2010 12:09 PM, Thomas Broyer wrote:
>> 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).
>
> The input type='email' isn't only about semantic. The browser has to
> check if the email is valid according to HTML5 specifications. Please,
> have a look at:
> http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address
>
> If the entered email address is invalid, the element will suffer from a
> type mismatch.

Of course, just like type=url requires the URL to be a valid absolute
URL, while hinting browsers to autocomplete based on your bookmarks
and/or search history (note: not your "account manager").

Would you use a type=number (that some browsers would present as a
spinner box) if the usernames were only digits?

(BTW, the syntax for an e-mail address to be considered valid is quite
lax, and can be easily reproduced using a pattern="" constraint, as I
already said)

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