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 12262 - select(), selectionStart, selectionEnd and setSelectionRange() should apply to <input type='email'>
Summary: select(), selectionStart, selectionEnd and setSelectionRange() should apply t...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Edward O'Connor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-08 00:11 UTC by Mounir Lamouri
Modified: 2012-10-16 17:27 UTC (History)
9 users (show)

See Also:


Attachments

Description Mounir Lamouri 2011-03-08 00:11:03 UTC
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?
Comment 1 Mounir Lamouri 2011-03-08 00:12:52 UTC
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.
Comment 2 Aryeh Gregor 2011-03-08 00:42:21 UTC
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.
Comment 3 Jonas Sicking (Not reading bugmail) 2011-03-22 00:50:57 UTC
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.
Comment 4 Mounir Lamouri 2011-03-30 16:13:45 UTC
(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).
Comment 5 Ian 'Hixie' Hickson 2011-06-14 01:15:23 UTC
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.
Comment 6 Michael[tm] Smith 2011-08-04 05:35:59 UTC
mass-move component to LC1
Comment 7 Anne 2012-07-10 08:24:09 UTC
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 8 contributor 2012-07-18 07:29:16 UTC
This bug was cloned to create bug 17986 as part of operation convergence.
Comment 9 Edward O'Connor 2012-10-16 17:27:31 UTC
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.