This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17986 - select(), selectionStart, selectionEnd and setSelectionRange() should apply to <input type='email'>
Summary: select(), selectionStart, selectionEnd and setSelectionRange() should apply t...
Status: RESOLVED DUPLICATE of bug 24796
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: 2015 Q1
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2012-07-18 07:29 UTC by contributor
Modified: 2014-09-25 22:38 UTC (History)
8 users (show)

See Also:


Description contributor 2012-07-18 07:29:13 UTC
This was was cloned from bug 12262 as part of operation convergence.
Originally filed: 2011-03-08 00:11:00 +0000
Original reporter: Mounir Lamouri <>

 #0   Mounir Lamouri                                  2011-03-08 00:11:03 +0000 
I don't understand why these IDL attributes and methods do not apply to <input type='email'>. Maybe when writing the specs the expected widget wasn't a text field but it seems that it is for all current implementations. Maybe those IDL attributes and methods should apply to <input type='email'> and should be removed only if the widget happen to not be a text field?
 #1   Mounir Lamouri                                  2011-03-08 00:12:52 +0000 
My last sentence might not be clear. I meant that we might make those IDL attributes and methods not applying to <input type='email'> if implementations move from a text field to something more complex where text selection has no meaning.
 #2   Aryeh Gregor                                    2011-03-08 00:42:21 +0000 
I assume the theory was maybe it would be tied into the user's address book (e.g., on a smartphone).  But even if it is, how is this different from autocomplete on a plain text field?  Selection still makes sense.
 #3   Jonas Sicking                                   2011-03-22 00:50:57 +0000 
What happens if the displayed value doesn't match the value in .value?

For example we've discussed adding a ", " to the end of the displayed value as to make it easier to add additional email addresses, however since this would result in an invalid address it wouldn't show up in .value or the submitted string.

Also, we might get fancy enough that we display the name along with the email address if the browser gets access to an address book. In that case the name would be displayed but not show up in .value.
 #4   Mounir Lamouri                                  2011-03-30 16:13:45 +0000 
Good point.

Then I don't know what we should do. I see a few possibilities:
- Allow selection methods and attributes and expect implementations to be clever we .value isn't the shown value ;
- Allow selection methods and attributes but also allow doing nothing if the widget is more complex than a simple text field ;
- Not allowing selection methods and attributes because some implementation might be more complex than a simple text field (this is not the case currently AFAIK).
 #5   Ian 'Hixie' Hickson                             2011-06-14 01:15:23 +0000 
Status: Rejected
Change Description: no spec change
Rationale: The type=email case isn't supposed to show a simple text edit box, especially when multiple="" is applied. Browsers might do it now, but I expect this will change in due course, as they one-up each other on the UI experience here.
 #7   Anne                                            2012-07-10 08:24:09 +0000 
From Daniel Bratell: 

I'm really not satisified with that interpretation because the arguments against selections on type=email ("we might to want to have a fancy UI that doesn't match a text string") apply to type=uri, type=tel and even type=password as well.

So I say that if someone wants to have a fancy UI they will have to deal with how to map selections between the string and the UI, or at least, type=email and type=url and type=tel should be treated identical in this respect.
Comment 1 Ian 'Hixie' Hickson 2012-07-20 05:37:59 UTC
I don't see how type=tel could possibly have a special UI, since the whole point is that it doesn't have a special UI. :-) The UI for type=password is pretty mature by now, so I am confident in letting it act like a textfield for selection purposes.

I agree that we might want to remove the selection APIs for type=url, but I don't really see that it could have much of a UI, unlike multiple type=email.

I think for now I'm going to leave the spec as is, and update it based on what browsers look like in a year or so.
Comment 2 Anne 2012-07-27 08:02:32 UTC
More from Daniel Bratell:

One of the bad things as the spec is now that any unsupported type will be parsed as type=text which has select() so as soon as you start supporting an input type the method disappears. So "unsupporting" browsers will have more functionality than "supporting" browsers, which is bad.
Comment 3 Ian 'Hixie' Hickson 2012-10-11 02:47:35 UTC
Well, the "supporting" browsers will have more functionality, in the form of better UI.

How would you implement .select() for type=button? Why is it different for type=email? If the answer is just "type=email's UI is a text field", then that's what will cause the API to change when I reopen the bug.
Comment 4 Ian 'Hixie' Hickson 2013-03-09 01:20:12 UTC
Punting to Q4 so we can study the UIs they settle on once they support multiple="" and so on.
Comment 5 Ian 'Hixie' Hickson 2013-10-01 21:52:18 UTC
Well the UI in Firefox and Chrome still leaves something to be desired (there's basically nothing different than an input text field as far as I can tell — no turning e-mail addresses into atomic units, no support for e.g. space-separated e-mail addresses (you have to explicitly give the comma), etc). So I guess I'll punt for a few more months and see if it improves at all.
Comment 6 Ian 'Hixie' Hickson 2014-09-25 22:38:27 UTC

*** This bug has been marked as a duplicate of bug 24796 ***