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 <mounir.lamouri@gmail.com>

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