[whatwg] RFC: <input type="username">
eitanadlerlist at gmail.com
Thu May 6 03:56:12 PDT 2010
>>>> The way I see it is that instead of browsers traversing the DOM looking
>>>> 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:
> 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
More information about the whatwg