[meter][progress][slider] Unify formatting API

[mj12albert]

NumberField uses Intl.NumberFormat, we can follow the format prop and adapt it for these range widgets:

Meter/Progress:

• ✅ Add Value subcomponent [Progress] Add format prop and Value component #1355
• ✅ Add format prop [Progress] Add format prop and Value component #1355
• Add locale prop to match [NumberField] Add locale prop #1488

Slider:

• ✅ Add format prop [Slider] Formatting API for the value displayed in Slider.Output #459
• Add locale prop to match [NumberField] Add locale prop #1488

[mj12albert]

@vladmoroz Wonder what you think about this quirk for formatting Slider? I'm not sure if feels similar enough to a conditional type to trigger you 😅

[mj12albert]

@colmtuite What do you think about Progress.Value/Meter.Value ?

[vladmoroz]

I agree with the suggestions

I'd also prefer if we converge on Slider.Value instead of Slider.Output too for consistency across the board.

[mj12albert]

Slider.Value instead of Slider.Output

The thing is Slider.Output is a <output> element which isn't suitable for the other components though

[vladmoroz]

The thing is Slider.Output is a element which isn't suitable for the other components though

Maybe it's just my opinion, but it's an internal detail that’s opaque to the user. To me, consistency of the API within the library is more important because there's fewer part names to remember.

I feel the same way about Select.Option vs Select.Item. TheOption name sticks out compared to everything else in Base UI.

[colmtuite]

@vladmoroz @mj12albert Agree on both. Select.Item and Slider.Value ftw.

[mj12albert]

I've found that the array form for Slider <Slider format={[options1, options2} /> is not good, it will cause the aria-valuetext of each input element will be announced with a different format which sounds weird.

Instead the (display value) rendering should use children:

<Slider.Value>{(formattedValues, values) => ''/* e.g. return a string */}</Slider.Value>