A use case for cursor control for number inputs

[justinbmeyer]

I would like to advocate for an API allowing programatic control and access of the cursor position for any input types that support behavior dependent on the cursor position.

A simple example might be changing the number inputs to use ArrowUp and ArrowDown keys to change a selected number in the range instead of only adding or subtracting 1.

This still works in Safari 9.1.2 as follows:

http://jsbin.com/juzepovowi/1/edit?js,console,output

Other uses of supporting some type of selection might be to show users some additional information about what is selected. For example, with long numbers it can be difficult to tell what an individual number represents. With the cursor, we could help with something like:

Thanks for your consideration.

[domenic]

I would like to advocate for an API allowing programatic control and access of the cursor position for any input types that support behavior dependent on the cursor position.

This is not a use case, so I'll ignore it.

A simple example might be changing the number inputs to use ArrowUp and ArrowDown keys to change a selected number in the range instead of only adding or subtracting 1.

This is a good use case. But, it's already possible! That is, it's already possible for all "input types that support behavior dependent on the cursor position".

input type="number" does not support such behavior, because implementations are allowed to render it as, e.g., a spinner dial, where there is no cursor. (I wouldn't be surprised if some mobile implementations do that today.) So this example doesn't work for input type="number", only for input types where you actually have a guarantee of a cursor, like input type="text". For those you can use the selection APIs.

Other uses of supporting some type of selection might be to show users some additional information about what is selected. For example, with long numbers it can be difficult to tell what an individual number represents. With the cursor, we could help with something like:

This is a good use case too. It's best addressed by CSS, which allows you to style certain parts of controls. Again, it only applies to controls which necessarily have cursors and selection.

[domenic]

Stepping back a bit, both of your examples seem to derive from wanting to present the user with a very specific experience, where text selection is present and the page author uses the selected text in various ways. If this is desired, then input type="number" is not an appropriate way of achieving that experience, since it's not guaranteed to support text selection: it's an explicit request to not control the user experience, but instead turn it over to the browser and let it use the conventions it thinks are best for inputting numbers.

For the case of such specific experiences, you're much better off with input type="text", perhaps with a pattern="" attribute or custom libraries, because that gives you more control over the experience.

[justinbmeyer]

@domenic these use cases came from people using syn to test behavior they already wrote. I'm advocating a bit here on their behalf.

I don't have control over the types of controls people use. Would you consider mimicking user interactions for testing and playback a valid use case?

Consider recording and simulating an interaction like:

Typing out a number like 1002200 then click after the last 2 and hit backspaces twice, leaving 10000.

The only way to make this work would be to model the behavior of text=number, knowing that if backspace was hit, to take the difference and see which character was deleted to infer the cursor position. The user's actions might be written out like:

Syn.type("1002200").selection(5).type("\b\b");

Similar care would be needed to play back the users action. If these actions are logged and played back, I couldn't see the cursor positioning changing. If a user can do something, I feel I should be able to programmatically put them back in the same state.

As the complete interact-able state of a control isn't exposed, we could never, for example, present the user with their last cursor position after refreshing the page.

Again, it only applies to controls which necessarily have cursors and selection.

Would it be possible to make cursor and selection APIs available within controls that do have cursors and selection? Let developers feature test?

Thanks again!

[domenic]

Would you consider mimicking user interactions for testing and playback a valid use case?

For sure! That sounds like a good thing to work on as part of the webdriver project or other browser automation tools. I'm not very familiar with them myself...

Would it be possible to make cursor and selection APIs available within controls that do have cursors and selection? Let developers feature test?

Yes! That's already the case. But input type="number" is not one of those controls.

[justinbmeyer]

For sure! That sounds like a good thing to work on as part of the webdriver project or other browser automation tools. I'm not very familiar with them myself...

Yeah, I've been working on Syn and it's parent project FuncUnit for years. To make sure I'm understanding you correctly, you agree that the difficulty in accurately simulating user behavior is a use case worth investigating? Should I create a new issue with that in mind?

I wasn't being clear with:

Would it be possible to make cursor and selection APIs available within controls that do have cursors and selection?

There is a cursor in desktop chrome / ff on type="number". A user can interact with it.

Where browsers have a cursor selection on text within type="number" could browsers expose ways of accessing the selection? Or, is it too important to maintain a unified interface for controls of the same type across browsers?

Thanks!

[domenic]

Yeah, I've been working on Syn and it's parent project FuncUnit for years. To make sure I'm understanding you correctly, you agree that the difficulty in accurately simulating user behavior is a use case worth investigating? Should I create a new issue with that in mind?

You should create a new issue on a different project, like webdriver, that is dedicated to browser automation. It's not an issue for the HTML spec, or for HTML APIs; browser automation is not what we design HTML APIs for.

Or, is it too important to maintain a unified interface for controls of the same type across browsers?

This is the case, I'm sorry to say. Otherwise it's too easy for sites to start depending on the behavior in popular browsers, thus painting us into a corner and preventing further evolution. As @Hixie said in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796#c24,

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.

[Ballpin]

Probably a few years late but it worked by turning the field type to text first then turn in back to number again.

[tolluset]

Probably a few years late but it worked by turning the field type to text first then turn in back to number again.

@Ballpin Thanks. Amazing solution!