Please also keep in mind a few of the decisions that led to OOUI's NumberInputWidget and current Design Style Guide component status, specifically the override of proprietary vendor UI extensions (mainly buttons) and instead adding buttons for increasing/decreasing input value by definable steps, while at the same time provide a minimum size for better click and touch usability.
A shortcoming of current implementation, that got surfaced with design peers, but not yet resolved, is position of buttons on different sides, add an unnecessarily effort to go in both directions quickly.

@Sarai-WMDE I'd like to expand on this in the Design Style Guide. When is a number input variant with no buttons advantageous to a buttoned one? We should capture this.

Hey, @Volker_E. The simple type=number input seems more convenient whenever users have to perform a single value input instead of modifying a default. We also considered this could be a core input type, on top of which the increment/decrement variant could be created.

There are two use cases for number inputs in the Simple Query Builder:

• limiting the number of results (in this case, it would make a lot of sense to use the number input documented in the DSG)
• with the Quantity input component (we considered that an input with increment/decrement would not make sense in this case)

Nonetheless, after conducting further investigation, it looks like we won't be creating this simple number input for now. Which means that a textInput with extended validation will be used to create the Quantity input, and also the more simple results limit feature (which I would advocate to replace for the DSG numberInput some time in the future).

This is done: https://wmde.github.io/wikit/?path=/story/vue_wikibase-components-extendednumberinput--basic