Add custom spin buttons to number field

[chrisdholt]

Currently the browser adds inner spin buttons to the number field input type. These spin buttons cannot be styled easily as they are part of the shadow DOM. This creates problems as the spin buttons take the browser styling and cannot be styled to align with the design system. Considering this, the spin buttons should be hidden for the time being.

I think it's worth a discussion as to whether or not we should add custom spin buttons to the number field component.

Outstanding questions:

• What are the perf tradeoffs for including this behavior?
• Should this be done at the base or MSFT level?
• Is work currently being done on the browser side to expose similar functionality?
• Should this be a render prop approach? This would allow users to opt into the behavior by passing their own spin buttons. We could build out the spin button as components which would make for an easier implementation.

[mdtauk]

WinUI is in the process of adding a NumberBox control to its Xaml library. There is a focus on it being touch friendly, but the same design could work for the Fast DNA Number Input Field.

[chrisdholt]

Thanks for the insight @mdtauk! I think we'd want this to support touch for sure. I'm leaning towards implementing a spin button specific to the increment and decrement functionality which the number field could optionally be composed with: https://w3c.github.io/aria-practices/#spinbutton

[mdtauk]

Yes, it should conform to the W3C expected behaviour, but I don't think that prohibits aligning the Up and Down buttons horizontally, instead of stacking them vertically, where there is not a lot of height available in the TextField.

[bheston]

Here is the design we proposed for the native platform controls update. We had to hold on it for now as the overlay proved to be difficult.
My goal was to maintain the up down visual relationship while supporting touch or generally larger hit points.
On the platform control we needed to maintain the narrow width due to an incredibly narrow 45px default field width.

[bheston]

@mdtauk for the WinUI control did you consider arrows instead of chevrons? Obviously there are lines and another "up" icon in the design you shared, but it might not be as discernible from a select box. Perhaps + and - would be good universal options too.

[mdtauk]

I only added to the discussion and design ideation for the WinUI NumberBox control that is now being built. I like that flyout approach, but there would need to be some thought as to focus and keyboard navigation, as well as accessibility concerns.

In the designs I worked on, it was mainly looking at other Windows Spinner Buttons, and making them more touch friendly. So side by side made sense, and they all used chevrons.

I mocked up a few other arrangements too

And to try to make the controls clear as to their behaviour, I also suggested a design language for Pickers, Combo Boxes, and Input Boxes

[KevinTXY]

for the WinUI control did you consider arrows instead of chevrons? Obviously there are lines and another "up" icon in the design you shared, but it might not be as discernible from a select box. Perhaps + and - would be good universal options too.

When I was developing NumberBox we decided that we'd include DecrementIcon and IncrementIcon IconSource properties to give devs easy control over this - this is reflected in the spec though not yet implemented.

[mdtauk]

@KevinTXY Has the WinUI Design team taken a pass at the NumberBox control design yet, or is it still in the building functionality stage?

The Fabric Web team, are using Chevrons, stacked vertically, with no allowance for Touch sadly.

If a consensus with the Fluent Design team can be reached, I hope all frameworks will adopt it, and maybe even backport it to WPF and the CommonControls in Win32

[KevinTXY]

I wouldn't know for certain but if I remember correctly a design review was a next step. Stepping button stylings especially in regards to localization and accessibility were major components of our discussions early in the summer. We picked a compromise of being friendly towards retemplating/restyling that was good for development and while i'm sure the issue is malleable that'd be something for Savoy to comment on.

Designing this functionality in a way that adapts towards several input types (including touch and gamepad) as well as vastly different screen sizes while still being multi-purpose is definitely non-trivial.

[mdtauk]

I wouldn't know for certain but if I remember correctly a design review was a next step. Stepping button stylings especially in regards to localization and accessibility were major components of our discussions early in the summer. We picked a compromise of being friendly towards retemplating/restyling that was good for development and while i'm sure the issue is malleable that'd be something for Savoy to comment on.

Designing this functionality in a way that adapts towards several input types (including touch and gamepad) as well as vastly different screen sizes while still being multi-purpose is definitely non-trivial.

I will include @SavoySchuler here just so he will be aware of the conversation. If consistency is part of the aim for WinUI, then talking to FastDNA and Fluent Web's designers could be useful.

[chrisdholt]

A new Proposal for spin buttons has started up at #2230

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[chrisdholt]

@EisenbergEffect would prefer to close this related to #3517 as we don't have number field yet. I'm happy to create a new task tracking the creation of that control; as it stands, this issue seems like it would be confusing as the control does not exist.