[UX] Bigger up/down arrows on number fields.

[klonos]

Steps to reproduce

These are a couple of examples of how our number fields are rendered (this is on Firefox, on Windows):

Actual behavior

The up/down arrows are really small and they do not match the rest of the admin UI style. They are also very small target for touch devices.

Expected behavior

Bigger, finger-friendly up/down buttons.

[klonos]

I like this:

...but it bothers me that it doesn't use type="number" ...or can it?

[klonos]

Related: https://css-tricks.com/numeric-inputs-a-comparison-of-browser-defaults/

[klonos]

Something like this perhaps?:

...but the buttons could be styled to match Seven and perhaps placed to the left/right of the number field.

[Dinornis]

Thanks for bringing this up. Yes the default browser arrows are too small on desktops. I like the Spinner up/down buttons.

[quicksketch]

Here's a pretty good article covering using jQuery UI's Spinner on both text and number input elements: https://www.tjvantoll.com/2012/07/15/native-html5-number-picker-vs-jquery-uis-spinner-which-to-use/

It's worth noting that jQuery UI Spinner is already in core, so if we want to use it, it's a matter of integrating it properly.

[olafgrabienski]

The up/down arrows are (...) also very small target for touch devices.

For input type="number", most touch devices don't display the arrows but a number pad, which is fine in my opinion. Reading the article linked by @quicksketch, jQuery Spinner in contrast seems not to show the number pad.

[jenlampton]

We need to be careful about styling away the default browser style. It's possible to really hurt the user experience by doing so. Having a number field look the same on all websites everywhere means that when someone sees one, they know how to use it. If we make Backdrop's number fields look different from everything else, users will not recognize it instantly.

I'd be in favor of adopting something else that's wildly popular (like maybe jQuery UI's Spinner) as long as we can confirm it is an improvement across all browsers, and only if we can do so in a way that won't break mobile devices opening the keypad.

[klonos]

I agree that using a 3rd party library and taking advantage of PIE is better in general, but in this case I would like it better if we could either find a solution or customize one that gives more touch surface for the +/- buttons. I mean Spinner is definitely an improvement over the current browser defaults and we should use that if we want something implemented quickly. But if we managed to somehow get those buttons on either side of the field, we would make it easier for those that use touch devices.

[jenlampton]

touch surface should be a non-issue on touch devices because they will open a number keyboard when the field has focus.

[jlfranklin]

Is it possible for a contrib module to override the core theming for controls? Presenting the browser default for these things, but allowing contrib to change it would be a good compromise.

[klonos]

As stated before, touch surface is a non issue because touch devices open a number keyboard instead.

I just tested on a touch laptop and the num keyboard does not pop up. You get the regular, tiny controls.

[jenlampton]

I expect, just like with select lists, it will be nearly impossible to style these elements at all, and for good reason: for consistency across the whole internet.

There is currently no core theming on number fields. What you are seeing right now is the behavior of whatever browser you are using (backdrop has no say in the matter). If your browser doesn't handle them in a way that is sensible (@klonos) it might be worthwhile creating an issue with the browser too, so that everyone else can benefit from a fix :)

That said, it is possible to use JavaScript to replace these standard elements with something else, and then style the new element to do something unique to backdrop.

(Keep in mind that if we bury the standard behavior we then won't benefit from other improvements browsers will implement over time.)

Personally, I'd prefer to stick with some standard, maybe something like jQuery UI. However, it looks like jQuery UI currently breaks the number keypad behavior on mobile devices, and since that's why we put in the number fields in the first place, it sounds like a non-starter.

Are there other examples of systems that have encountered this issue? What is the rest of internet doing about it?

[jlfranklin]

That said, it is possible to use JavaScript to replace these standard elements with something else, and then style the new element to do something unique to backdrop.

This is closer to what I expect a contrib module to provide. Similar to how Better Select replaces a select control with checkboxes or radios, a contrib module could add $element['attached']['js'][] = 'myspinnylib.js' in a hook, or replace the entire element with different HTML that includes the input field plus two buttons or something.

Using a stock HTML5 number field is, IMHO, best for core's default implementation.

[klonos]

Are there other examples of systems that have encountered this issue?

Well, I don't know about other browsers, but in firefox that issue was reported 4 years ago 😞 https://bugzilla.mozilla.org/show_bug.cgi?id=947365

What is the rest of internet doing about it?

That's what I've found:

https://developer.apple.com/ios/human-interface-guidelines/ui-controls/steppers

http://www.virtuosoft.eu/code/bootstrap-touchspin https://github.com/istvan-ujjmeszaros/bootstrap-touchspin

[jenlampton]

This is closer to what I expect a contrib module to provide. [...] Using a stock HTML5 number field is, IMHO, best for core's default implementation.

This is how I feel too, at least until there's a clear winner in terms of suitable alternatives. Today there's nothing to stop a contrib module from adding TouchSpin, for example.