[Slider] Replace reversed with rtl support on horizontal sliders

[eps1lon]

Breaking change

• Remove the reverse property from the Slider component.

---

Fix: Slider interactions and thumb positions in rtl themes

This was discussed internally.

Reasons for the removal:

• The previous implementation was completely broken for right-to-left themes
• We currently don't have any precedent that we support local reversal of a component that is not done because of right-to-left language support.
• Supporting the reverse prop would result in 8 different combinations of the Slider just for direction and orientation. This is very error prone.
• It follows WAI-ARIA slider authoring practices
• It follows the material design specs. The vertical slider is kept regardless.
• The original PR [Slider] Add support for vertical/reversible sliders #4571 did not provide real world examples or a concrete use case

Pinging @lwansbrough in case he wishes to make a more compelling case for reverse sliders.

Follow up after merge:

• Minimum value for vertical slider should be the bottom

[oliviertassinari]

Great!

[oliviertassinari]

Why not remove this section all together?

[eps1lon]

I was thinking about people looking for the missing prop but the changelog entry and this PR is probably sufficient.

[oliviertassinari]

The reverse property was introduced in #11040.

[sakulstra]

Just a side note here: reverse or vertical reverse was one of the main obstacles when trying to port this to native input range components. If this pr gets merged it might make sense to reconsider a native implementation

[oliviertassinari]

Just a side note here: reverse or vertical reverse was one of the main obstacles when trying to port this to native input range components. If this pr gets merged it might make sense to reconsider a native implementation

@sakulstra What's the advantage of the native implementation? From what I understand, we get the accessibility and form submission for free. I would love to explore this path. Especially if it means simplifying the internal implementation.

[sakulstra]

@oliviertassinari what I thought the advantages would be:

• better performance
• native multi touch support
• native support for step
• i expected it to be more lightweight
• native onchange events

The disadvantage is, that browser implementations and feature support widely differ even in modern browsers - so getting things right is unnecessarily hard:
https://css-tricks.com/sliding-nightmare-understanding-range-input/

[matanassa]

current rtl behavior
https://i.gyazo.com/9258b17c7bc7aa1764c939f4d9382d7a.mp4

@sakulstra any Idea?

[oliviertassinari]

@wenduzer Did you follow the 3 steps of our RTL guide?

[matanassa]

@oliviertassinari yes

[eps1lon]

@wenduzer Could you open a separate issue and follow the issue template? This looks like the behavior before this PR got merged.

[matanassa]

maybe npm repo isn't updated?