12262 2011-03-08 00:11:03 +0000 select(), selectionStart, selectionEnd and setSelectionRange() should apply to <input type='email'> 2012-10-16 17:27:31 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED WONTFIX P2 normal --- 1 mounir eoconnor annevk ayg eoconnor ian jonas mike public-html-admin public-html-wg-issue-tracking shadow2531 public-html-bugzilla oldest_to_newest 46481 0 mounir 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? 46482 1 mounir 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. 46489 2 ayg 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. 46898 3 jonas 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. 47055 4 mounir 2011-03-30 16:13:45 +0000 (In reply to comment #3) > 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. 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). 49548 5 ian 2011-06-14 01:15:23 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html 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. 54094 6 mike 2011-08-04 05:35:59 +0000 mass-move component to LC1 69767 7 annevk 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. 70434 8 contributor 2012-07-18 07:29:16 +0000 This bug was cloned to create bug 17986 as part of operation convergence. 76411 9 eoconnor 2012-10-16 17:27:31 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: No spec change. Rationale: See comment 5.