Additional info on the use case:

On mobile devices you must use a 'number' input type so that you get the numeric keyboard open when focusing on the field.  In this case you also need a way to select the number, so that you can immediately type a replacement for the value.

Specifying the select() method to apply for all input types would be sufficient, setSelectionRange() is not necessary (at least for this use case).  Currently select() is also limited to the same input types as setSelectionRange().

Yes I never understood why the specs don't support this. It is also odd that an input of type number can allow for

I would like to see the selection API permitted on <input type="number"> as well.  In fact, browsers like Chrome did support this until very recently.  For many people this is a breaking change in the name of 'adhering to spec'.

Here is one use case that immediately comes to mind:

In many of my applications it is desirable to have real-time instantaneous validation of user input, particularly for numbers.  What this means is that instead of allowing malformed input (eg "123foo456") and then later rejecting this only when then user attempts to submit, rather we wish to prevent any keystrokes, etc, that would result in an invalid input immediately as they occur.  Usually this is paired with some kind of visual feedback (eg flashing red border, textual message).

This requires the use of `selectionStart` and `selectionEnd` in order to compute the resultant value after the keystroke or paste event.

Essentially, if the user has the ability to create a selection or move the caret position in the <input>, the DOM API should allow script to at least query the selection.

If the value is "123456", and you select characters 4 through 6, what would be selected? Hint: the browser is allowed to render that as:

   [ 000,123,456.000 |^|v]

It's also allowed to render it as:

   [ One hundred and twenty three thousand, four hundred and fifty six ]

It's also allowed to render it as:

 [+] ..... ..... ..... ..... ..... ..... .....
     |   | | 0 | | 1 | | 2 | | 3 | | 4 | | 5 |
  >> |   | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | <<
     |   | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
     ''''' ''''' ''''' ''''' ''''' ''''' ''''' [.]

...or as:

  0                100k              200k
  |----------------------v-------------|
                      123,456

At least select() should be supported, which selects the entire value (if applicable).

From a practical, implementor's perspective:

The variability of the allowed input element styles is a major pain in mobile web app development in general.  You have to use 'number' type so that the keyboard is for numeric input, but you have to run through hoops (and browser specifics) to control the styling.  (And yes, controlling styling is important.)

In practice, no browser could switch their number input from a relatively simple text-based layout (with possible up/down controls) without breaking a lot of web apps.

*** Bug 24814 has been marked as a duplicate of this bug. ***

How would it break Web apps?

I don't really understand why you need to be manipulating the selection of a type=number field at all. What's the use case?

I too have an issue with the lack of support for selectionstart and selectionend for input type number. The use case I can think of is when we want to limit the min/max number the user can input depending on the the number place. Lets say we want to only allow the user to input 43-67. When the user highlights the first digit and inputs a number, I'd like to know to know what range the user is doing it so I can restrict the number value, where x is the user input and has to be x >= 4 || x <= 6. I understand there is a min and max attribute value but that doesn't stop the user from inputting that number directly unless they use the spinner control.

I know we can achieve that using input type text but to me it's very confusing as to why input type number even allows the input of non numbers in the first place. Why is maxlength and pattern not supported, amongst other things. These things should just be available to all inputs in general. 

To me it sounds like input type number is only valuable in the mobile context.

Hi all I'm jumping in this late (had I known these changes were going in I would have spoke up earlier!)

Since Chrome just updated to remove this from number fields app(s) I work on now fail in Chrome.

Similar to others I've used the selectionStart, selectionEnd, and setSelectionRange() props/methods on fields to validate, add, remove, insert content on many fields (mostly type="text") but also for email, number, url etc.

There's 2 underlying problems.

1.) Currently (AFAIK) all user agents render an <input type="number"/> field as a text box... the only difference is that on modern mobile (phones/tablets) when the OS provided on-screen keyboard pops up, it *defaults* to the one that best matches the field type (e.g. the number pad).

From a usability perspective, this is awesome! and thus has been adopted wide scale on any numerical field in web apps (and apps with WebView's) everywhere.

However the web is a living, moving thing... and many apps need to support all kinds of devices/OSes including older ones, and including touch-screen devices that were created *before* touch-screen devices had a decent on-screen keyboard solution. (I'm gonna quote this as any touch screen before the iphone)

As a result in *many* enterprise situations (think the kiosk in your local mall, office/floor directory in a skyscraper, Point Of Sale, Hospital, Restaurant, Book store/library, etc.) developers needed to create a software based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input where no phyical keyboard was available (and using the Windows "104" onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc. that could take down the terminal)

Long story short, these on-screen keyboards need to use JavaScript to know where they are inserting characters, or "moving" the cursor within a field to let the user input values correctly.

There's also cases where a number field will invoke a "special" tool (tax/tip/percentage/standard calculator) that can be used to clear, add/remove/overwrite values into a field.

My vote for what it is worth is 100% in favor of bringing full support back for these properties/methods.


Problem 2.

If the powers that control the specs here disagree with web developers about the importance of these properties/methods... there's little we can do - however like all good coders should I was already testing to see if the JavaScript object reference to the field I was working with supported the "setSelectionRange" method (side note, Internet Explorer's previous lack of support for these props/methods required this test to use their legacy text-selection methods).

Sadly Chrome passes the test and tells me that my field does indeed support this method only to throw an exception in the log if I try to use it.

e.g. I have:
if(typeof(field.setSelectionRange) == 'function'){...}
or
if(typeof(field.selectionStart) != 'undefined'){...}


IMHO this is almost worse.  I'm being told that these members are valid, yet they most certainly are not with this latest change in Chrome.


Sadly I'm now stuck... customers are auto updating to the latest version of Chrome and I'm in panic mode trying to determine what to do.

Do I change all my <input type="number|email|url|..."/> fields back to <input type="text"/> to ensure that Chrome (and future browsers that adopt this behavior) are not completely borked at the cost of deliberately adding a major usability failure for all other mobile devices... or wait and hope that these oversights get reverted/fixed right away.

On further thought... if we insist on keeping this regression it would be even better that *if* a user agent decides on a device that they are *not* showing a number field as a textbox control, *only* then they can either mark the properties/methods as undefined... OR better yet keep them... whereby they report the selectionStart and selectionEnd as (n-1) (ditto for range: (n-1 - n-1)) until the user blur's the field at which point the selection updates to start=0, end=(n-1) range matches full selection.

(In reply to Aaron Labiaga from comment #8)
> The use case I can think of is when we want to limit the min/max number
> the user can input depending on the the number place.

Please don't do this. It drives me crazy as a user.

Take the example you gave of 43–67. I have entered "67". Now I want to change it to 57. I put the cursor at the front, I type "5" (so now it says "567") and then I delete the "6" (so now it says "57"). Why should that not be possible?


> I understand there is a min and max attribute value but that doesn't
> stop the user from inputting that number directly unless they use the
> spinner control.

Right. And so what? Let the user type what they want. When the user tries to commit the value, then report it as out-of-range if necessary (the browser will even do that for you if you invoke the right API).

Seriously, limiting user input in this way is incredibly bad UI.


> I know we can achieve that using input type text but to me it's very
> confusing as to why input type number even allows the input of non numbers
> in the first place.

What it allows is up to the user agent.


> Why is maxlength and pattern not supported, amongst other things.

What's the use case?


> These things should just be available to all inputs in general. 

That would just encourage authors to do things like you've described.


(In reply to stephen.cunliffe from comment #9)
> 
> 1.) Currently (AFAIK) all user agents render an <input type="number"/> field
> as a text box... the only difference is that on modern mobile
> (phones/tablets) when the OS provided on-screen keyboard pops up, it
> *defaults* to the one that best matches the field type (e.g. the number pad).

_Currently_ being the operative word here.


> As a result in *many* enterprise situations (think the kiosk in your local
> mall, office/floor directory in a skyscraper, Point Of Sale, Hospital,
> Restaurant, Book store/library, etc.) developers needed to create a software
> based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input
> where no physical keyboard was available (and using the Windows "104"
> onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc.
> that could take down the terminal)
> 
> Long story short, these on-screen keyboards need to use JavaScript to know
> where they are inserting characters, or "moving" the cursor within a field
> to let the user input values correctly.

That's a pretty horrifying thought, but let's put that aside for now: why would these apps need to use type=number when they show the on-screen keyboard? (Or even <input> for that matter.) If they're showing their own keyboard, the <input> isn't really being used as a text input at all, it's just being used as an output widget. If you're going to go to the trouble of designing an entire on-screen keyboard, just go the whole hog and design your own widget, don't try to reuse the proper widget.

(But really, if you find yourself designing your own on-screen keyboard in HTML, you've probably made some fundamental design mistakes.)


> There's also cases where a number field will invoke a "special" tool
> (tax/tip/percentage/standard calculator) that can be used to clear,
> add/remove/overwrite values into a field.

Not sure how this would have any impact here. Nothing stops you from clearing, adding, removing, or overwriting values. You don't need to manage the selection to do that.


> if(typeof(field.setSelectionRange) == 'function'){...}
> if(typeof(field.selectionStart) != 'undefined'){...}

This isn't unexpected; the browser _does_ support these features, they just don't apply to <input type=number>, <input type=button>, etc.

Since you're not supposed to use them with type=number at all, it's not something we've tried to make easy to detect.

You can detect it, though, in theory, by checking to see if an exception is raised or not.


> Sadly I'm now stuck... customers are auto updating to the latest version of
> Chrome and I'm in panic mode trying to determine what to do.

Just rely on the browser to provide the interface.

Our use-case is implementing customized numeric inputs.  Consider the input elements in the screenshot I've attached.  The user can tap on the hours, and the number is automatically selected.  They can enter two digits, and the focus jumps to the minutes, which is automatically selected to allow overwriting that number as well.

What we currently have to do is use number inputs, which are positioned such that any possible spinners are hidden behind other elements.  Needless to say, any browser that switches their number input to something other than a text field + spinner buttons will break all such designs.

The layout could be achieved easier with a text input, but on mobile devices / tablets this brings up the text input keyboard, not the numeric input keyboard.  This would be unacceptable from a UX perspective.

I'm not arguing this is the best possible element for entering a time / number, I'm arguing this type of custom input element should be possible.  I don't see any reason why selecting the entire number (in case it is shown in a text field) should be prohibited.

Mobile IE actually does not support setting the selection of a number field, and the UX is clearly inferior.

Created attachment 1444 [details]
Example of custom input element usage

Example screenshot relating to my previous comment.

(In reply to stephen.cunliffe from comment #9)
> As a result in *many* enterprise situations (think the kiosk in your local
> mall, office/floor directory in a skyscraper, Point Of Sale, Hospital,
> Restaurant, Book store/library, etc.) developers needed to create a software
> based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input
> where no phyical keyboard was available (and using the Windows "104"
> onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc.
> that could take down the terminal)

This is exactly my use case.
The company I work for makes a Point Of Sale solution and we have just been stung by this bug.

We can't just change the inputs to text instead of number as we need them to work correctly on mobile devices, as people have already mentioned.

(In reply to Sampo N from comment #12)
> 
> The layout could be achieved easier with a text input, but on mobile devices
> / tablets this brings up the text input keyboard, not the numeric input
> keyboard.  This would be unacceptable from a UX perspective.

Would <input type=text inputmode=numeric> solve this use case for you?

I wouldn't recommend using type=number if you're designing your own widget. As you say: any browser that switches their number input to something other than a text field + spinner buttons will break all such designs. The lack of selection is the least of your concerns.


(In reply to Jayd from comment #14)
> We can't just change the inputs to text instead of number as we need them to
> work correctly on mobile devices, as people have already mentioned.

Why don't you just use type=number on mobile and type=text when you have the fake keyboard showing? It's trivial to just switch the "type" attribute when you show the keyboard.

In general, if your widget is type=number, you can't rely on a keyboard making any sense. In fact, at that point, you're not relying on the widget at all, you're just using it as an output field.

Personally, though, I would recommend using another approach for securing the kiosk. The strategy you describe seems like a losing proposition to me.

> > 1.) Currently (AFAIK) all user agents render an <input type="number"/> field
> > as a text box... the only difference is that on modern mobile
> > (phones/tablets) when the OS provided on-screen keyboard pops up, it
> > *defaults* to the one that best matches the field type (e.g. the number pad).
> 
> _Currently_ being the operative word here.

Yes currently. As is currently no OS presents anything different so why go changing the way the code works and break things?

I'd also argue... that unless the field is actually trying to allow input within a *very* restricted range (and there is a field type for that!) that I'd be hard pressed to dream up any other control type for the entry vs. an input box. Since I've used electronic devices where a mouse/cursor/caret/keyboard has been available none to my knowledge have seeked (& found) an alternative and better solution.

This change to the API (without a need to actually remove it (e.g. a control implementation being pushed forward that WON'T work with the selection props/methods - that CAN'T easily side step the non-applicable parts) just seems like a quest for Astronaut Architecture in an Ivory Tower.


> 
> 
> > As a result in *many* enterprise situations (think the kiosk in your local
> > mall, office/floor directory in a skyscraper, Point Of Sale, Hospital,
> > Restaurant, Book store/library, etc.) developers needed to create a software
> > based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input
> > where no physical keyboard was available (and using the Windows "104"
> > onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc.
> > that could take down the terminal)
> > 
> > Long story short, these on-screen keyboards need to use JavaScript to know
> > where they are inserting characters, or "moving" the cursor within a field
> > to let the user input values correctly.
> 
> That's a pretty horrifying thought, but let's put that aside for now: why
> would these apps need to use type=number when they show the on-screen
> keyboard? (Or even <input> for that matter.) If they're showing their own
> keyboard, the <input> isn't really being used as a text input at all, it's
> just being used as an output widget. If you're going to go to the trouble of
> designing an entire on-screen keyboard, just go the whole hog and design
> your own widget, don't try to reuse the proper widget.
> 
> (But really, if you find yourself designing your own on-screen keyboard in
> HTML, you've probably made some fundamental design mistakes.)

If you have an alternative for a touchscreen kiosk device (w/o physical keyboard) running an OS like Windows and a web application running in a browser (with no OS supplied S/W keyboard) I'm all ears! However this has been solved many times over in JavaScript... you might be surprised just how common this actually is.


> > if(typeof(field.setSelectionRange) == 'function'){...}
> > if(typeof(field.selectionStart) != 'undefined'){...}
> 
> This isn't unexpected; the browser _does_ support these features, they just
> don't apply to <input type=number>, <input type=button>, etc.
> 
> Since you're not supposed to use them with type=number at all, it's not
> something we've tried to make easy to detect.
> 
> You can detect it, though, in theory, by checking to see if an exception is
> raised or not.
> 
> 
> > Sadly I'm now stuck... customers are auto updating to the latest version of
> > Chrome and I'm in panic mode trying to determine what to do.
> 
> Just rely on the browser to provide the interface.

Similar to the suggestion below... our only alternative at this moment is to force a change to the field's type attribute on the fly.

Realistically this is just a hack to overcome this regression... and we're going to have to be careful as this won't work in IE8 or below, or any IE browser running content that is not in Standards mode...
<sarcasm>Yay browser detection!</sarcasm>


Maybe I am really missing something here but AFAICT the type="number" attribute applied to the HTML input tag is no different than every other implementation I've seen over the years at other software levels.

It provides "hinting" to the field that can determine that this string field:
a.) might be best shown with a spinner
b.) might be best shown right aligned (in a LTR locale)
c.) might be best to limit the character input to digits, and valid delimiters (as per locale)
d.) might be best to enforce validation upon submitting

However since a number can be any value from (-infinity to infinity) and that number is essentially a string of digit characters in a rectangle that displays the characters horizontally with no UA imposed restrictions on *how* the user decides to populate the string I find it really frustrating that we're intentionally trying to hinder developers by removing the basic selection methods.

If someone has come up with a new (desirable) & future way of entering a number like "1250" that doesn't render said number into a horizontal string I'd be curious to know about it.

Sadly it looks like trying the hack of converting the field to a type="text" to get the selection fails (at least in Chrome) because it resets the selection.

The new, current hacky solution is to have an onload handler (pick your favorite library) that creates a dummy input of type="number" that is NOT added to the DOM... attempt to call setSelectionRange() on it and if it fails, scan the entire document for input elements of type="number" and forcibly convert them to type="text" because this particular browser has dropped support for the useful properties/methods.

Hopefully no other browsers follow suit before this issue is addressed.  Sigh

I've been maintaining the jquery.alphanum library for the last 18 months. This change has broken the library which has been very inconvenient for it's userbase.
https://github.com/KevinSheedy/jquery.alphanum/issues/19

There has been 18 months worth of work done developing, testing and fixing this library on the basis of the selection api being available.

Quoting the w3 design principles:
"When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths

This feature has been available in all browsers for a long time now and has become widely adopted by developers. I think this is one case where the spec should follow the implementation rather than the other way round.

https://github.com/Mottie/Keyboard is affected by this as well.  I rely on this library to supply on-screen keyboards and numpads for industrial automation controllers.  These are kiosk-style systems where the UI/HMI is a Single Page Application.  This is not a public-facing website, eCommerce app, etc.

The HMI is also remotely accessible from any device with a browser. We enable the use of the virtual keyboard via a query string.  For PCs, phones, etc. the absence of the query string foregoes our custom keyboard in favor the native keyboard (which for PCs, we expect that it's a physical keyboard).

As such, we like to using numeric inputs as appropriate so that we get the best result from the user agent.  We also rely on min, max, and step attributes as well to automate the validation.  We also use step to enforce floating point vs. integer fields.

It is also noteworthy, that our UI/HMI does not fit the classic model of a web form where there is a separate and distinct submission action.

Since this change has had major impact on production environments that were using the properties/methods that were previously available we've had to hack a workaround to get the proper behavior back.

I've posted a question on StackOverflow that includes my answer on how we are currently solving this.

http://stackoverflow.com/questions/22381837/how-to-overcome-whatwg-w3c-chrome-version-33-0-1750-146-regression-bug-with-i

If other developers are stuck during this interim period and need a solution please feel free to use this code (or any other solution answers posted)

As for the committee that designs these specifications, I sincerely hope you reconsider these changes. I see no upside to removing these properties/methods and a whole pile of downsides.

(In reply to stephen.cunliffe from comment #16)
> Yes currently. As is currently no OS presents anything different so why go
> changing the way the code works and break things?

Nothing in the spec has been changed here; the selection APIs didn't apply to type=number from the beginning.

The idea is that in the future, browsers will get better, and selection will no longer make sense.

It would be sad for us to paint ourselves into a corner and prevent progress.


> I'd also argue... that unless the field is actually trying to allow input
> within a *very* restricted range (and there is a field type for that!) that
> I'd be hard pressed to dream up any other control type for the entry vs. an
> input box. Since I've used electronic devices where a
> mouse/cursor/caret/keyboard has been available none to my knowledge have
> seeked (& found) an alternative and better solution.

There have been lots of kinds of numeric controls, especially for the cases of limited ranges. Dials and sliders, for example. The clock widget in recent Android releases is a numeric control over a narrow range.

But actually, even if it's just a text field with up and down buttons, it still varies: commas used for thousands separation, how many decimal places are shown, and other locale-specific adjustments, are all things that you can't predict and that are commonly different in different numeric controls.


> This change to the API--

There hasn't been a spec change here.


> If you have an alternative for a touchscreen kiosk device (w/o physical
> keyboard) running an OS like Windows and a web application running in a
> browser (with no OS supplied S/W keyboard) I'm all ears!

I recommend running an OS that isn't like Windows, and using an OS-supplied soft keyboard.

Android, for example, is particularly well-suited for this kind of deployment, as it is open source and can be completely locked down.


> Realistically this is just a hack to overcome this regression...

Having a Web-based on-screen keyboard is already a hack; making the input field into a text field is far less of one, since it is actually turning the control into what you need.

At the point where you're providing a software keyboard, it's not longer a numeric input field. It's a custom input field, and the best basis for that is type=text.


> and we're
> going to have to be careful as this won't work in IE8 or below, or any IE
> browser running content that is not in Standards mode...
> <sarcasm>Yay browser detection!</sarcasm>

I thought we were talking about a kiosk situation? Surely you control the software running on this kiosk? Maybe I don't understand the use case.


> Maybe I am really missing something here but AFAICT the type="number"
> attribute applied to the HTML input tag is no different than every other
> implementation I've seen over the years at other software levels.

The type="" attribute specifies the kind of input so that the browser can provide a different UI. For example type=button is a button, type=text is a text field, type=password hides input. Well, type=number is a numeric input field, where the displayed value is adjusted by the user agent and might not match the submitted value.


> It provides "hinting" to the field that can determine that this string field:
> a.) might be best shown with a spinner
> b.) might be best shown right aligned (in a LTR locale)
> c.) might be best to limit the character input to digits, and valid
> delimiters (as per locale)
> d.) might be best to enforce validation upon submitting

e.) might render different values than are submitted
f.) might not be a text field at all


> However since a number can be any value from (-infinity to infinity)

That depends on the attributes, in particular min/max.


> that number is essentially a string of digit characters in a rectangle

Nothing in the spec says that.


> displays the characters horizontally with no UA imposed restrictions on
> *how* the user decides to populate the string

Nothing in the spec says that either. In fact, I would suggest that every UA does provide some limits on how the UA populates the string, for example, I don't know of any that currently support speech input on type=number.


> If someone has come up with a new (desirable) & future way of entering a
> number like "1250" that doesn't render said number into a horizontal string
> I'd be curious to know about it.

In particular on mobile UAs it is not uncommon for controls to show popup dialogs when they are selected. For example, this is how a date control gets shown on some versions of iOS:

   http://www.deque.com/wp13/wp-content/dquploads/iphone-input-type-date.png

There's no reason to believe some browsers won't do this for numeric inputs also.


(In reply to stephen.cunliffe from comment #17)
> Sadly it looks like trying the hack of converting the field to a type="text"
> to get the selection fails (at least in Chrome) because it resets the
> selection.

You should apply this hack early (as soon as you know you're going to be managing the input for the control). I don't recommend waiting until the control is focused or anything like that.


> The new, current hacky solution is to have an onload handler (pick your
> favorite library) that creates a dummy input of type="number" that is NOT
> added to the DOM... attempt to call setSelectionRange() on it and if it
> fails, scan the entire document for input elements of type="number" and
> forcibly convert them to type="text" because this particular browser has
> dropped support for the useful properties/methods.

Why would you use type=number for UAs where you're going to be providing the input UI anyway?


(In reply to Kevin Sheedy from comment #18)
> I've been maintaining the jquery.alphanum library for the last 18 months.

I don't understand the point of this library. Could you elaborate?


> Quoting the w3 design principles:
> "When a practice is already widespread among authors, consider adopting it
> rather than forbidding it or inventing something new."
> http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths
> 
> This feature has been available in all browsers for a long time now and has
> become widely adopted by developers. I think this is one case where the spec
> should follow the implementation rather than the other way round.

The problem is that this practice has always been non-standard (you haven't been following the standard), and the standard behaviour is intended to protect the ability for innovation on the Web, which is good for users. http://www.w3.org/TR/html-design-principles/#priority-of-constituencies


(In reply to Brandon White from comment #19)
> https://github.com/Mottie/Keyboard is affected by this as well.  I rely on
> this library to supply on-screen keyboards and numpads for industrial
> automation controllers.  These are kiosk-style systems where the UI/HMI is a
> Single Page Application.  This is not a public-facing website, eCommerce
> app, etc.

I don't understand why anyone with an HTML-provided on-screen keyboard would want to use type=number instead of type=text.


> The HMI is also remotely accessible from any device with a browser. We
> enable the use of the virtual keyboard via a query string.  For PCs, phones,
> etc. the absence of the query string foregoes our custom keyboard in favor
> the native keyboard (which for PCs, we expect that it's a physical keyboard).

When the string is there, change it to type=text.


> As such, we like to using numeric inputs as appropriate so that we get the
> best result from the user agent.  We also rely on min, max, and step
> attributes as well to automate the validation.  We also use step to enforce
> floating point vs. integer fields.

Yeah, that'll be harder for you (you'd have to reimplement that logic and, when changing the type attribute, move the data to data-* attributes).

Fundamentally you have to make a decision: either rely on the UA to do the input control logic for you, including providing an on-screen keyboard if appropriate, or, implement the control yourself.


(In reply to stephen.cunliffe from comment #20)
> 
> As for the committee that designs these specifications, I sincerely hope you
> reconsider these changes. I see no upside to removing these
> properties/methods and a whole pile of downsides.

I've explained the upside multiple times here, if you're not seeing it then you're not looking for it.

I see this as a few separate issues that are all getting muddled together.


Issue #1: The spec only gets questioned when the new implementation breaks things.

When browsers implemented the <input type="number"/> field to behave **exactly** like an <input type="text"/> field (with the exception that it also supported min/max/step etc. and on modern mobile devices was a hint to open the numeric keyboard on focus) developers **continued** to depend on built in JavaScript properties/behavior available to all existing text/password/textarea fields.

Should we have expected/depended on this? yes/no/maybe... this was also tricky because browsers that didn't support number yet, just fell back to text anyway.

Should we blame the browser developers for not adapting to the strict guidelines of the HTML5 specs (which only went CR on Feb 4th, 2014) for leading web developers down the garden path?

The answer depends on knowing the final outcome of this "change". I'm using quotes because depending on your viewpoint this is either a change, or was never supported. (a question of implementation vs. spec)


Issue #2: The spec has chosen not to implement properties/behavior that web application developers obviously want for reasons that are currently theoretical only.

I get that there is nothing that states that a numeric input control must render a single line rectangle container that contains character input... however ALL current implementations DO.

Please do not point to date widget implementations as an argument for a number field (that's Apples vs. Oranges)

We all agree that if you have a very limited range of numbers you are accepting (e.g. a scale of 1..10 that rendering those values in a select list, set of radio buttons, or the way-more-appropriate <input type="range"/> field makes **perfect** sense!) however for the generic <input type="number"/> where the 'range' is essentially potentially from negative infinity up to positive infinity... There is NO user interface control that I can think of that will adapt to that level of flexibility other than the "rectangular input box".  I have not seen in any application, on any device, on any platform that has provided a better solution... in fact if there was one, it would already be gaining traction/adoption.


Issue #3: Developers are smart people! If one is building a new rendering control for <input type="number"/> in their browser that doesn't let users insert characters where they want e.g. I had "35" and I meant "345" but more importantly won't be able to provide a meaningful interaction for JavaScript attempting to get/set the selection range... the solution is simple!... just provide a stub method that does nothing or returns the overall min/max indexes (since it doesn't apply).

In the long run the field still contains a value... that value is presumed to be numeric (level of enforcement TBD) but it is a String... when the form is submitted over HTTP to the server it is a String... the server still needs to parse it back into a number and validate that it got one because it is a String... in fact every single input control sending data back to the server is sending a String(*1) and the most basic manipulation methods on Strings require the ability to get/set/manipulate substrings.


I really don't get what possible advantage we are gaining by not letting web application developers get or set the cursor position or get or set the selection ****IF**** the user agent is rendering the value in a single line input box.






(*1)Ignoring Blobs, and binary file attachments of course.

There is a valid concern that setSelectionRange is problematic, since even in a rectangular box browsers can render a number either "1234567", "1,234,567", "1 234 567" or a number of different ways, while the value will always return "1234567".  (It might be possible to describe a proper logic here, e.g. select the digit range that would be selected if the number were formatted without localization.)

However, I see no reason why select() method should not work *in case it is rendered as a selectable text field*.  The method would be a no-op if character selection is not applicable.

According to the spec the proper way to make a number input that renders like a text box would be <input type="text" inputmode="latin digits">, however *no* browser supports opening a numeric keyboard in this case.

I created a test page for the various input types:  http://sampo.kapsi.fi/files/numeric-input.html

(In reply to stephen.cunliffe from comment #22)
> Issue #1: The spec only gets questioned when the new implementation breaks
> things.
> 
> When browsers implemented the <input type="number"/> field to behave
> **exactly** like an <input type="text"/> field (with the exception that it
> also supported min/max/step etc. and on modern mobile devices was a hint to
> open the numeric keyboard on focus) developers **continued** to depend on
> built in JavaScript properties/behavior available to all existing
> text/password/textarea fields.
> 
> Should we have expected/depended on this? yes/no/maybe... this was also
> tricky because browsers that didn't support number yet, just fell back to
> text anyway.
> 
> Should we blame the browser developers for not adapting to the strict
> guidelines of the HTML5 specs (which only went CR on Feb 4th, 2014) for
> leading web developers down the garden path?
> 
> The answer depends on knowing the final outcome of this "change". I'm using
> quotes because depending on your viewpoint this is either a change, or was
> never supported. (a question of implementation vs. spec)

This particular part of the spec went to "CR" at least as far back as 2010, FWIW. (It is marked as "Ready for first implementations", and the state was last edited in 2010.)

But yes, more earlier review would definitely be great. I don't know what we can do to encourage this.


> Issue #2: The spec has chosen not to implement properties/behavior that web
> application developers obviously want for reasons that are currently
> theoretical only.
> 
> I get that there is nothing that states that a numeric input control must
> render a single line rectangle container that contains character input...
> however ALL current implementations DO.
>
> Please do not point to date widget implementations as an argument for a
> number field (that's Apples vs. Oranges)
> 
> We all agree that if you have a very limited range of numbers you are
> accepting (e.g. a scale of 1..10 that rendering those values in a select
> list, set of radio buttons, or the way-more-appropriate <input
> type="range"/> field makes **perfect** sense!) however for the generic
> <input type="number"/> where the 'range' is essentially potentially from
> negative infinity up to positive infinity... There is NO user interface
> control that I can think of that will adapt to that level of flexibility
> other than the "rectangular input box".  I have not seen in any application,
> on any device, on any platform that has provided a better solution... in
> fact if there was one, it would already be gaining traction/adoption.

I think this oversimplifies the situation (e.g. it ignores that some UAs put thousands-separators in the displayed value, which is a relevant point for the selection API, because it interferes with the precise positions that would be selected).

But sure, the UIs are all very similar today. Consider this, though: Forms came in April 1993. Mobile Safari introduced a new form control set in June 2007, fourteen years later.

I don't want to be the reason we can't introduce a new form-factor decades hence.


> Issue #3: Developers are smart people! If one is building a new rendering
> control for <input type="number"/> in their browser that doesn't let users
> insert characters where they want e.g. I had "35" and I meant "345" but more
> importantly won't be able to provide a meaningful interaction for JavaScript
> attempting to get/set the selection range... the solution is simple!... just
> provide a stub method that does nothing or returns the overall min/max
> indexes (since it doesn't apply).

I agree that this would be fine for many authors.

On the other hand, we've experienced many times over the years that some authors rely on the weirdest edge cases in the most obscure of ways. Look at the HTML parser's crazy edge cases for some examples. The smart developers aren't claiming that their UTF-8 pages are encoded as UTF-16, but there are still sufficient UTF-8 pages labeled as UTF-16 that we have to explicitly have that mapping in the spec, as crazy as that is. The spec is _full_ of stuff like this.

What about if the page somehow depends on the position of the cursor to function right? What if the page somehow relies on the selection changing from the whole thing being selected to nothing being selected to know when to do something critical to furthering interaction on the page?

We don't know what people will end up depending on.


> In the long run the field still contains a value... that value is presumed
> to be numeric (level of enforcement TBD) but it is a String... when the form
> is submitted over HTTP to the server it is a String... the server still
> needs to parse it back into a number and validate that it got one because it
> is a String... in fact every single input control sending data back to the
> server is sending a String(*1) and the most basic manipulation methods on
> Strings require the ability to get/set/manipulate substrings.

Yes, but these strings are already today in some browsers not the string that is displayed.


> I really don't get what possible advantage we are gaining by not letting web
> application developers get or set the cursor position or get or set the
> selection ****IF**** the user agent is rendering the value in a single line
> input box.

The same advantage as we got, in 2007, from the decision, in 1993, not to require that all select widgets show a drop-down box in the specific way that browsers in 1993 all did.


(In reply to Sampo N from comment #23)
> There is a valid concern that setSelectionRange is problematic, since even
> in a rectangular box browsers can render a number either "1234567",
> "1,234,567", "1 234 567" or a number of different ways, while the value will
> always return "1234567".  (It might be possible to describe a proper logic
> here, e.g. select the digit range that would be selected if the number were
> formatted without localization.)
> 
> However, I see no reason why select() method should not work *in case it is
> rendered as a selectable text field*.  The method would be a no-op if
> character selection is not applicable.

That could work. I've filed bug 25663 for this.


> According to the spec the proper way to make a number input that renders
> like a text box would be <input type="text" inputmode="latin digits">,
> however *no* browser supports opening a numeric keyboard in this case.

It's inputmode=numeric, actually. Where did you see "latin digits"? (Not that I found browser support for inputmode=numeric yet either, unfortunately.)

http://www.w3.org/TR/2003/REC-xforms-20031014/sliceE.html and http://www.w3.org/TR/2006/REC-xforms-20060314/sliceE.html specify inputmode="latin digits".  I was unable to find any spec that would define inputmode="numeric".

The recommendation dates to 2003, and no user agent to my knowledge has adopted it.

That's XForms.

HTML's inputmode="" attribute is defined in the HTML spec:

   http://whatwg.org/html#attr-fe-inputmode

I ran a set of tests for the inputmode attribute (number, tel, email, url) on various current devices / browsers that have an onscreen keyboard that pops up on focus.

Sadly at this time (May 12/2014) I've found NO mobile browsers on any OS that support the attribute. This included iOS, BlackBerry10, Android, FirefoxOS & WindowsPhone... on all default browsers and (in the case of iOS/Android) on extra installed browsers (Firefox, Chrome, Opera). Not a single browser supported the attribute.

This is sadly quite frustrating as it would solve a lot of the text selection issues that developers are facing due to some browsers already "removing" the text selection options on the "specialized" input fields. :-(

Yeah, agreed. Can you file bugs on the big ones for that?

(In reply to Ian 'Hixie' Hickson from comment #11)
> (But really, if you find yourself designing your own on-screen keyboard in
> HTML, you've probably made some fundamental design mistakes.)

I'm sad to say that some of the most popular Smart TVs around do not allow apps to use a System-provided keyboard.  Instead, we're forced to use JavaScript and HTML-based keyboards from their libraries that rely on .selectionStart and .selectionEnd to get and set the position of the caret in an input box.

The top two manufacturers' (Samsung & LG) on-screen keyboards are poorly coded and don't support most HTML5 input types, though, but my point is that sometimes we don't have a choice.

> If the value is "123456", and you select characters 4 through 6, what would
> be selected? Hint: the browser is allowed to render that as:
>
>   [ 000,123,456.000 |^|v]

While I get the reasoning for disallowing selection manipulation on <input type="number">, I don't get the reasoning for the same on <input type="email">.  This input type is always going to work like a text input, isn't it?

The poor design choice there might be trying to target a device with such a poorly implemented browser. :-)

For type=email, have a look at the GMail "To" field for an example of what an e-mail entry widget might look like. Notice that it's not a simple text field.

> --- Comment #30 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
> The poor design choice there might be trying to target a device with such a
> poorly implemented browser. :-)
I almost wrote that myself in my first reply!

> For type=email, have a look at the GMail "To" field for an example of what an
> e-mail entry widget might look like. Notice that it's not a simple text field.
Yet it handles text selection just fine by excluding the "complete"
email addresses that were already entered. :-) Technically, URL, tel or even ordinary text inputs could be handled the same way (it's really no different to the "Tags" input at http://stackoverflow.com/questions/ask).

My point is that, unlike type="number", that could be rendered many different ways graphically and interacted with in different ways by the user, type="email" will always need some kind of direct input via a keyboard.  User selection is just as likely as it would be on a text input.

Arguably, this *is* the spec's fault for the following part of http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection:

> For input elements, calling these methods while they don't apply, 
> and getting or setting these attributes while they don't apply, 
> must throw an InvalidStateError exception. Otherwise, they must act
> as described below.

When it should (in my opinion, of course) just work in cases where the input rendering for those types is similar or identical to a standard text input field, and silently fail otherwise.  That would seem like the least destructive course of action to take, in terms of backward and cross-browser compatibility.

Even on type="number" elements, using your examples,

 [+] ..... ..... ..... ..... ..... ..... .....
     |   | | 0 | | 1 | | 2 | | 3 | | 4 | | 5 |
  >> |   | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | <<
     |   | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
     ''''' ''''' ''''' ''''' ''''' ''''' ''''' [.]

and

  0                100k              200k
  |----------------------v-------------|

These kinds of graphical interfaces could just silently do nothing on attempts to programmatically set selection, and getting could just return 0 for `selectionStart` and `selectionEnd`.  This would give developers the means to work any required magic on elements of this type when the browser or OS doesn't do anything special with them and just renders them in the same way they all do at the moment.

But it's not that simple.

For example, in the numeric case, the display could be:

   "12,345.6700"

...while the value is:

   "12345.67"

What should selecting characters 2 to 4 do?

For e-mail, the display could be:

   "foo@افغانستا.example.org"

...while the value is:

   "foo@xn--mgbaal8b0b9b2b.example.org"

What should selecting characters 6 to 7 do?

(In reply to Ian 'Hixie' Hickson from comment #32)
> But it's not that simple.
> 
> For example, in the numeric case, the display could be:
> 
>    "12,345.6700"
> 
> ...while the value is:
> 
>    "12345.67"
> 
> What should selecting characters 2 to 4 do?

Perhaps we could transparently pretend the selected value is:

    "1|234|5.67"

and display it as:

    "1|2,34|5.6700"

I don't think this would particularly matter to the user as any changes to the selection would be handled identically in either situation.

> For e-mail, the display could be:
> 
>    "foo@افغانستا.example.org"
> 
> ...while the value is:
> 
>    "foo@xn--mgbaal8b0b9b2b.example.org"
> 
> What should selecting characters 6 to 7 do?

Of course, this is trickier, but any of the following seem like they'd be better alternatives than throwing an error that wasn't always thrown:

 - screw with the developer and pretend they didn't select anything, but adjusting .selectionStart should still move the cursor/caret based on a "best guess".  For example, whilst the cursor is outside the arabic text, move it normally.  Whilst inside the arabic text, treat the passed value as more or less to move the cursor by at least 1 "displayed" character.

 - Introduce a "displayed value" property and have the selection reflect that instead. At least then we're offering a way to fix the broken code.

It would just be nice if we could have a solution where code didn't have to change the input type to "text" before it could work with these elements.

(In reply to Ian 'Hixie' Hickson from comment #32)
> For e-mail, the display could be:
> 
>    "foo@افغانستا.example.org"
> 
> ...while the value is:
> 
>    "foo@xn--mgbaal8b0b9b2b.example.org"

IIRC, the recommendation is that applications supporting IDN use the Unicode format for domain names internally, and the domain is converted to Punycode only for legacy applications / protocols.  I definitely hope no browser will start converting type="email" input values to Punycode!  Some user-provided formatting can easily be lost, e.g. capitalization.

(In reply to Andy Earnshaw from comment #33)
> (In reply to Ian 'Hixie' Hickson from comment #32)
> > But it's not that simple.
> > 
> > For example, in the numeric case, the display could be:
> > 
> >    "12,345.6700"
> > 
> > ...while the value is:
> > 
> >    "12345.67"
> > 
> > What should selecting characters 2 to 4 do?
> 
> Perhaps we could transparently pretend the selected value is:
> 
>     "1|234|5.67"
> 
> and display it as:
> 
>     "1|2,34|5.6700"
> 
> I don't think this would particularly matter to the user as any changes to
> the selection would be handled identically in either situation.

If we do that then how would you maintain the selection when the user has selected:

    "12|,345.670|0"

...or:

    "12,|345.67|00"


> > For e-mail, the display could be:
> > 
> >    "foo@افغانستا.example.org"
> > 
> > ...while the value is:
> > 
> >    "foo@xn--mgbaal8b0b9b2b.example.org"
> > 
> > What should selecting characters 6 to 7 do?
> 
> Of course, this is trickier, but any of the following seem like they'd be
> better alternatives than throwing an error that wasn't always thrown:
> 
>  - screw with the developer and pretend they didn't select anything, but
> adjusting .selectionStart should still move the cursor/caret based on a
> "best guess".  For example, whilst the cursor is outside the arabic text,
> move it normally.  Whilst inside the arabic text, treat the passed value as
> more or less to move the cursor by at least 1 "displayed" character.

This is not the way to write good APIs. If you want to move the caret around arabic text, use a text field, not an e-mail field.


>  - Introduce a "displayed value" property and have the selection reflect
> that instead. At least then we're offering a way to fix the broken code.

What if the "displayed value" is a bitmap, because the control is a pen input control? There's nothing in the spec that disallows browsers from making that implementation choice.


> It would just be nice if we could have a solution where code didn't have to
> change the input type to "text" before it could work with these elements.

I don't understand why you would _not_ want to use type=text if what you want is a text input.


(In reply to Sampo N from comment #34)
> (In reply to Ian 'Hixie' Hickson from comment #32)
> > For e-mail, the display could be:
> > 
> >    "foo@افغانستا.example.org"
> > 
> > ...while the value is:
> > 
> >    "foo@xn--mgbaal8b0b9b2b.example.org"
> 
> IIRC, the recommendation is that applications supporting IDN use the Unicode
> format for domain names internally, and the domain is converted to Punycode
> only for legacy applications / protocols.  I definitely hope no browser will
> start converting type="email" input values to Punycode!

It's actually required by the spec right now. See bug 15489.



Note that I intend to make select() work with these controls, since that can be done interoperably. See bug 25663.

I'd still very much like to argue that **IF** a user agent renders an input field as a horizontal string of characters (e.g. as it currently does for text, password, number, email, url, tel etc.) that providing options for a selection start/end via JavaScript is not only helpful but darn near FUNDAMENTALLY IMPORTANT/EXPECTED.

Yes, in theory, a user agent **Could** decide to render a input of type number field as a triangle field with random placement of digit characters and delimiters above, below and offset from each other... but **UNTIL** the rendering arrangement changes to anything other than a **HORIZONTAL STRING OF CHARACTERS** there is no point in removing these useful API calls from the fields. [1]

If the W3C is still determined that they want to play the game of "well maybe a user agent might..." then lets at least not remove these properties/methods **UNTIL** the attributes to provide a keyboard hint to user agents is available.

e.g. if I can still use a text field, but hint I want the numeric keyboard then fine (this sucks but is at least better than the current spec)

<input type="text" inputmode="number"/>
<!--request numeric keyboard since we want numeric input... but don't add the type="number" because the current spec removes JavaScript access to the selection if we set the type.-->

Notes: [1] I'm willing to place bets that for as long as I plan being a developer (+/-25 more years) that numeric input will remain as a horizontal string of characters. Yeah it may be smartly filtered to not let users type "purple" as a numeric value... but it will still be a horizontal field of characters.

I agree with Stephen (comment #36).  Ideally, we'd have a way to specifically ask for a textual input that can only contain digits.  But until there's a way to do this in a widely supported way, removing this functionality is very detrimental.

"When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths

Bug 25663 does alleviate the problem significantly, I believe.  At least it covers our use cases.

(In reply to Ian 'Hixie' Hickson from comment #35)
> (In reply to Andy Earnshaw from comment #33)
> > Perhaps we could transparently pretend the selected value is:
> > 
> >     "1|234|5.67"
> > 
> > and display it as:
> > 
> >     "1|2,34|5.6700"
> > 
> > I don't think this would particularly matter to the user as any changes to
> > the selection would be handled identically in either situation.
> 
> If we do that then how would you maintain the selection when the user has
> selected:
> 
>     "12|,345.670|0"
> 
> ...or:
> 
>     "12,|345.67|00"

I'm not entirely sure, I'm just suggesting potential alternatives to gimping the things we can do in the browser, hoping that we can hammer out the details of a solution once we decide there's going to be one.  

Do you have any examples of browsers implementing number elements like this?  Because presumptuously formatting a number against how it may have been intended to be displayed seems like bad UI design.  Maybe the <input type="number"> element should accept an LDML-based number pattern[1], giving the developer more control and knowing what to expect when playing around with the selection.

> This is not the way to write good APIs. If you want to move the caret around
> arabic text, use a text field, not an e-mail field.

Why shouldn't JavaScript be able to move the caret around an email field, though?  Because it's easier to just disallow it than think up a working solution?

> >  - Introduce a "displayed value" property and have the selection reflect
> > that instead. At least then we're offering a way to fix the broken code.
> 
> What if the "displayed value" is a bitmap, because the control is a pen
> input control? There's nothing in the spec that disallows browsers from
> making that implementation choice.

If the displayed value is a bitmap, then it's no longer an input accepting text and the user wouldn't be able to control text selection on it either.  Just like an <input type="checkbox|radio|hidden|etc">.  Perhaps "displayedValue" isn't the correct term to use.  "selectableValue", then, or "textValue", or whatever you like.

> > It would just be nice if we could have a solution where code didn't have to
> > change the input type to "text" before it could work with these elements.
> 
> I don't understand why you would _not_ want to use type=text if what you
> want is a text input.

Sometimes things like that aren't in our control.  Going back to my earlier example of the IME, for example.  It's open source, someone wants to use it, they have an email input in their app because they want to take advantage of the native browser capabilities.  The open source IME can't write to it because of how the API currently works.

JavaScript coders can work around nitty gritty discrepancies between selected text and element value if we're given enough information, we've been doing it forever with everything else.  I just have a hard time believing that there's no workable alternative to just tearing out pre-existing functionality.

[1]: http://www.unicode.org/reports/tr35/tr35-numbers.html#Number_Formats

This thread is not being productive; we're just going around in circles. You explain that you need the API and are willing to put up with the API only being available on browsers that don't do anything clever, I explain that the API can't work and that making it work only in some cases would lead to interop issues and force browsers to not provide the good UI they are supposed to be able to provide. We basically have two positions: you are arguing for enabling authors to do more now, and I'm arguing for enabling user agents to do more later. These are mutually exclusive. We're basically arguing about whose concerns should be rejected.

Here's an alternative proposals for how to make progress here:

For each use case that you have — having a script-provided IME that works with any text control, being able to determine whether a user's input will result in valid input or not so that the user can't enter invalid data, whatever the use cases are — file a bug specifically for that use case. That will help us focus the discussions on specific use cases, and will help us make sure we're arguing about how to solve solutions in ways that address everyone's concerns.

While I believe that creating a new bug will "lose" a lot of the thoughts in this conversation I do see that this is starting to cycle.

I've therefore taken your suggestion and created a new bug to deal with the bad-timing implementation of the *removal* of JS APIs before the *implementation* of the only native 'correct' solution.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26695

" Request that user agents implement the inputmode attribute BEFORE removing the selection properties/methods on extended HTML5 input types"

*** Bug 26695 has been marked as a duplicate of this bug. ***

So this seems to be going in circles and attempts to mitigate this issue by ensuring that inputmode is supported before removal [1] of these methods isn't making any traction as it appears the w3c has no intention of suggesting that vendors implement a simple new feature before removing [1] an old feature.

Thus this now seems to be a battle of technicalities in the spec vs. what application developers were used to (and continue to expect).

For every example of currently-in-use-in-production use of these APIs on number fields @Ian Hixie shoots these down on the premise that in the future we can't guarantee that numeric input fields will be rendered in the browser as a horizontal box of characters.

2 thoughts
a.) I have no issue with @Ian's thoughts here - I know my web history and thus admire Ian and his tremendous efforts... as one professional to another I merely want to open up the discussion and our minds to the possibilities/realities that we are dealing with.
b.) Although I concur that agents may render a numeric input any way they please and it may not reflect our current concept of a number field - I'd like to challenge that in concept this is true, in reality it is not (see below)

Keeping the APIs available (e.g. the status quo) on number fields sees its biggest challenge with those that feel these APIs may make no sense if vendors render these input fields differently.  I agree (technically) however I'll argue that (realistically) this isn't possible.  To explain why, lets look at the "requirements" of implementing a numeric input control.

Requirements:
1.) User should be able to enter any valid floating point number from NegativeInfinity to Infinity
2.) Obvious invalid values should likely be blocked e.g. "chocolate cake" isn't a number in any language that I know of
3.) If the OS of your browser presents a soft-keyboard when this control is focused... be a sweetie and show a numberpad of some kind UX FTW

So... how can we render such a control? we could use a slider! and the user slides over a range to pick a value! Well yes, but the granularity required to provide selections would require 2xInfinity pixel precision (just for integer values, not including decimals) thus that won't work... in fact the range slider is already its own field type "range" that takes a min/max/increment to solve the cases when you have a limited set of values.

How about a dial like a volume knob? spin clockwise to increase, counter-clockwise to decrease! Well... same problems... decimal values can't be done easily and if you need to spin several thousand times to get to 100k this isn't going to work.

Ok, how about a standard ~text~ box with up/dn spinners! (e.g. I think Opera does this) yup... that works... and the UX is improved if the user wants to bump up/down the value an integer at a time.

However as history has shown... over the last 40 years that we've had GUIs... that we have yet to find an alternative to the "horizontal text box control" that meets the full requirements of being able to enter any number possible. e.g. the requirements are just way to broad to provide a better control.  Yes you can add spinners... you could render negative values with red text by default... set the text alignment as "right" by default for LTR locales that feel this is a better default... and the control can be smart enough to not let you enter non (digit/decimal/comma/scientific notation characters)... but no one in 40 years has dreamed up a better control (usability wise) than the horizonal input to serve this need. (with the exception of course of a limited range of numbers (often integers only)... which we now have a range field type for.

But wait!... when the iphone came out it used a funky calendar widget that was better than a plain input box! so we can't blah blah blah....

Agreed, calendar widgets have long been a better way for users (again usability) to input dates.  Users can pick "This Saturday" much easier than having to know that it is "2014-09-06" and have to type that in to a text box.  We know this because every OS/App we've seen over the past 20-30 years has implemented something special for this very specific **constrained** input purpose.


As much as I'm open to the idea that browsers could render a different type of control for a number input in the future... the REALITY is that they very likely won't because it just isn't practical.

What if the user wants to paste a value? what do they focus before pasting if there isn't a box to paste into?

What if they are typing a big long "serial number" type number (all digits) and they realized they mistyped.  Do we not want them to be able to put the cursor back in the correct position and edit their value?

e.g. before: "123567890" (woops! I missed the 4!)
             "123|567890" (place mouse/cursor in-between 3 & 5 to type/tap "4")
             "1234|567890"

What if they are typing in their odometer reading?

"34538398|"
"3453839|" (wait, it just changed (backspace!))
"34538399|" (wait, it just changed again)
"34538|" (wait, it just changed again (backspace!))
"34538400|" (wait, it just changed again)


Again, if someone can point out a better usability based control for numeric input that meets the requirements for a number field that doesn't render as a horizontal string of number characters in a box of some kind - please do so! I haven't seen one in the history of 40+ years of GUI programming.  However if we can't come up with one, lets please put this issue to bed that some vendor "might" come up with something new that isn't capable of having a JS selection API!




[1] Re: Removing these APIs from number fields. Yes it is understood that technically they are not being removed since they were "never" defined... except that they were... <input type="unrecognized"/> defaults to an <input type="text"/> rendering in HTML (and always has)... when <input type="number" came along if a browser didn't recognize it, it just rendered a "text" field which was a fine fallback. However if it was a modern touch device it used this "hint" to tell the OS... when this field gets the focus, show the numeric input field - not the alpha keyboard. (essentially this mimic'd the inputmode attribute's intentions) - sweet! So every developer that cared about usability switched their type attributes to number (where applicable) and boom! the mobile web took off!  Then the specs for HTML5 pushed onwards and it was determined (back whenever) that the text selection methods shouldn't apply to the number field and thus in the spec they were not available as properties/methods.  However since I can only presume that most browser vendors created number fields as a "subclass" of input text fields (or a flag on a text field) that by default they inherited all the properties/methods of a regular input field.  Alas when Chrome dug deep into the spec and realized that these properties/methods did not apply, they *removed* them from their implementation.  AFAIK they were the first (and ONLY to-this-date) browser vendor to REMOVE these properties/methods.

We can argue till we are blue in the face that these APIs were never part of HTML5... but as a migrating spec... migrating from HTML4.x which did contain these APIs on input elements of type=text (or type falls back to text) they were implemented by ALL browser vendors already... e.g. they were the cow paths that developers were expecting would be paved.

I encourage you to file a bug for each specific use case for which you want these APIs, as suggested in comment 40.


The argument that we can't think of a better UI today so we should make it impossible for someone to come up with one later is IMHO a flawed premise. This isn't academic — we have seen this exact thing happen before with existing select controls. <select> had the same UI for literally a decade before Apple changed it in Mobile Safari. If we had constrained how the <select> UI should work, they wouldn't have been able to do that.

> I encourage you to file a bug for each specific use case for which you want
> these APIs, as suggested in comment 40.

There's no point because we've posted several already but they get turned down on the fundamental mis-match with this idea that a new solution for the UI will come along and render the past 40 years of 'textbox' input obsolete.

> <select> had the same UI for literally a decade before Apple changed it in
> Mobile Safari. If we had constrained how the <select> UI should work, they
> wouldn't have been able to do that.

This isn't quite correct. <select> as I understand it is a control that renders a set list of user-un-editable options.  If the multiple flag is not set, then the control allows for a single selection of any of the options and a change event fires for developers to handle that selection.

How this renders *is* up to the browser vendor. Windows has always shown a [_items_][v] box.  Mac OS has a similar box (much prettier) but with an up/down arrow.  Both will open the list (up or down on the screen depending on position) when focused to allow a selection.  In fact in Windows 8/IE10 Microsoft changed their rendering to a open a box of options with a 2px border, an animation as it loads, and the list opens "centered" on the selected value for a better touch experience.  In Mobile Safari (as well as Android & BlackBerry & Firefox) a different styled list pops up but the fundamental ability to select an option still persists.

In theory a user agent could choose to render a select list as a "horizontal pillbox" but the fundamental concept is the same... render an ordered list of options, let the user select one.


<input/> elements are inherently different. They expect the user to enter a *custom* value (not select from a set list).  This is the root of this discussion.

<select>, <input type="radio"/>, <input type="checkbox"/>, <input type="range"/>, <input type="date"/>(* [1]) are all forms of *constrained* input to a limited set of known values.

[1] Ok, a date can be almost any value... but it is really 1 of 365 values for every year that we consider valid (for most people this is *currently* a value between 1800 and 2100)

Providing a UI control with good UX for a set list of values is fairly easy and we've been improving these every year for the past 20+ years.

However the opposite are *custom* value elements.

<input type="text"/>, <input type="password"/>, <textarea/>, <input type="number"/>, etc.

In these field types a user can enter almost any value they want, cut, copy, paste, edit, delete.

My argument is that even though it is *technically* possible for someone to invent a new way to input a number... the reality is that for a number field that handles all of the requirements... there is nothing beyond a horizontal input box that can improve upon what we've already got.

If there was, we'd have 100's of sample UI's for a number input to chose from (and Google, Apple, Microsoft, Mozilla) would all already have these controls in their OS's because they would provide a superior experience.

I challenge anyone to provide a control for numeric input (that meets all the requirements) that does not at its core include a horizontal input box.  I'd be willing to put money on it.

However if we can't even dream up a single example that improves upon the existing horizontal input box - then why are we fighting over removing developer access to get/set the selection within this field?

This is "cutting off our noses to spite our face".

I'm offering to try to address your use cases. I can do that if you file bugs for those use cases.

*** Bug 17986 has been marked as a duplicate of this bug. ***

I work on https://github.com/bitovi/syn.  This library is used to simulate user interaction for testing purposes.  It allows people to click and type much like a user does. We use setSelectionRange to control the cursor position.  Currently, the library doesn't work in FF 51.0.1 with number and similar form controls.

As noted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796#c4, this is not possible in the form requested. In the two years since the last activity on this bug, nobody has taken the time to file their separate use cases as a bug (note: a use case is not "use setSelectionRange()"; it's something you actually want to be able to accomplish for a user of your website). Let's close this.

If you have actual use cases, please file them at https://github.com/whatwg/html/issues/new. Again, follow the process at https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F and do not focus on a particular solution (like making setSelectionRange() behave a certain way), but instead focus on what an actual user of your website is trying to accomplish which they cannot do with the current set of APIs in HTML.