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

[Eitan Adler]

>>>> 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.

Here are some possible solutions to allow the use of something like
<input type="login/username"> along with an email
1) change type="login" to role="login" (and thus allow a
text/selec/email/whatever). Based on the feedback so far this is now
my preferred solution.
2) add a role to form element and have the browsers continue to rely
on id/name/class