[material-ui][Slider] Set CSS writing-mode and update vertical slider docs

[mj12albert]

User-facing changes

Note: This only affects vertical sliders.

Previously, we recommended preventing the default behavior on the left and right arrow keys when using vertical sliders as there were some browsers' inconsistencies resulting in the keys being reversed. When preventing the default behavior, the left and right arrows didn't change the slider's value, and only the up and down arrows did.

• If you did follow our recommendation, nothing will change for you. If you wish, you can stop preventing the default now and the left and right arrow keys will work consistently with LTR/RTL modes.
• If you didn't follow the recommendation, the left/right arrow keys will be swapped and will now be consistent with LTR/RTL modes.

What this PR changes

• Set the CSS writing-mode property in the <input type="range"> element's styles to ensure orientation is exposed correctly in the accessibility tree
• Added more keyboard interaction tests using fireEvent.keyDown, most of the existing tests use fireEvent.change which did not catch some incorrect behaviors
• Handle all keypresses in the keydown handler instead of splitting them across the keydown and change handlers. This takes care of a side effect of using CSS writing-mode to fix the a11y issue – it causes native range inputs to render top-to-bottom in LTR (reference), and bottom-to-top in RTL, which is counter-intuitive 😆 (but its the spec).

Closes #44237

• I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

• docs/data/material/components/slider/slider.md

@material-ui/core: parsed: +0.12% , gzip: +0.14%

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 7981bcc

[mj12albert]

Fixed the rest of the comments ~

[aarongarciah]

@mj12albert arrow keys are still reversed. Is that expected? e.g. in https://deploy-preview-44537--material-ui.netlify.app/material-ui/react-slider/#vertical-sliders

[mj12albert]

@mj12albert arrow keys are still reversed. Is that expected? e.g. in https://deploy-preview-44537--material-ui.netlify.app/material-ui/react-slider/#vertical-sliders

🥲 nope – let me fix this

Fix for reversed arrow keys is still pending

[mj12albert]

the only quirk is that the writing-mode only PR would still have to (temporarily) explain why the left/right arrow keys appear reversed as the reason is now differen – with -webkit-appearance it's because of a browser bug, with writing-mode it's because the spec is odd

Clarification: I may not have been specific enough here (though this is just to document the fact and doesn't affect the PR now) - with writing-mode, it's ArrowUp/ArrowDown that become reversed, instead of Left/Right, because the spec says it fills from top-to-bottom, "up" is the direction that represents "less" so ArrowUp will decrement the value instead of incrementing it (and same for ArrowDown)

https://codesandbox.io/p/sandbox/material-slider-writing-mode-reversed-up-down-s7x6qf?file=%2Fsrc%2FDemo.tsx%3A34%2C1

[DiegoAndai]

@mj12albert I'm confused, you shared two demos:

1. https://codesandbox.io/p/sandbox/material-ui-slider-writing-mode-jkw4kn?file=%2Fsrc%2FApp.js%3A1%2C1
2. https://codesandbox.io/p/sandbox/material-slider-writing-mode-reversed-up-down-s7x6qf?file=%2Fsrc%2FDemo.tsx%3A34%2C1

In the first one, both sliders increase with the Up Arrow
In the second one, the slider decreases with the Up Arrow

But both have writing-mode: "vertical-lr", what am I missing? 😅

[mj12albert]

In the first one, both sliders increase with the Up Arrow

This first one is with the fixes in this PR!

In the second one, the slider decreases with the Up Arrow

This second one is just a fork of the VerticalAccessibleSlider demo on master, the only change being -webkit-appearance: slider-vertical is replaced with writing-mode, just to show that without the changes in this PR, different keys become reversed for a different reason if only that CSS is changed @DiegoAndai

[DiegoAndai]

This first one is with the fixes in this PR!
This second one is just a fork of the VerticalAccessibleSlider demo on master

I see, it makes sense now 😅.

From the description:

Handle all keypresses in the keydown handler instead of splitting them across the keydown and change handlers

I see that in this PR we're handling all keys in the keydown handler, but I don't see the removal from the change handlers. Am I missing something?

---

@aarongarciah If we released this in a minor version, we would have to add an explanation to the changelog. The breaking change would be that for the users who didn't follow our recommendation of preventing default. For them, the left/right arrow keys would be swapped when updating.

I consider it a 'softer' breaking change as it will only affect people who didn't follow the recommendation. But, there will probably be some users that notice the change and are not happy with it, so if we wanted to play it extra safe, we could hold until v7. Your call.

[DiegoAndai]

Users don't have to add this themselves, right? I would remove/rewrite this, otherwise I think people might think they need to provide it themselves.

[mj12albert]

Updated!

[aarongarciah]

I think we can ship this in a minor.

[mj12albert]

I see that in this PR we're handling all keys in the keydown handler, but I don't see the removal from the change handlers. Am I missing something?

f463c0f
I added a comment there, if you asked as well then it's for sure un-obvious 😅
The change handler handles changes from Pointer and Touch events, it wasn't obvious to me either, thought it wasn't needed until I deleted it and the tests failed

[DiegoAndai]

I added a comment there, if you asked as well then it's for sure un-obvious

I didn't explain my question well enough 😅 here it goes again:

• Before this PR, createHandleHiddenInputKeyDown only handled PageUp, PageDown and shift+arrow changes. So I assume ArrowRight, for example, was handled elsewhere.
• With this PR, createHandleHiddenInputKeyDown is now handling all keys, including the ArrowRight example.
• But I don't see ArrowRight handling being removed from anywhere, so is it being handled in two places?

[mj12albert]

• But I don't see ArrowRight handling being removed from anywhere, so is it being handled in two places?

@DiegoAndai In the keydown handler, preventDefault is called on all the relevant keys:

material-ui/packages/mui-material/src/Slider/useSlider.ts

Lines 357 to 371 in c279aea

	const createHandleHiddenInputKeyDown =
	(otherHandlers: EventHandlers) => (event: React.KeyboardEvent<HTMLInputElement>) => {
	if (
	[
	'ArrowUp',
	'ArrowDown',
	'ArrowLeft',
	'ArrowRight',
	'PageUp',
	'PageDown',
	'Home',
	'End',
	].includes(event.key)
	) {
	event.preventDefault();

So it wouldn't get handled twice (I think lots of tests would have broke if it did)

[DiegoAndai]

@mj12albert and what about:

[...] I assume ArrowRight, for example, was handled elsewhere.

I can't seem to find where it was handled before this PR

[mj12albert]

I can't seem to find where it was handled before this PR

@DiegoAndai in the keydown handler prior to this PR, some keys (e.g. Arrows without holding Shift) were not explicitly handled and therefore not event.preventDefault-ed:

https://github.com/mui/material-ui/blob/master/packages/mui-material/src/Slider/useSlider.ts#L347-L375

So those keys will continue to trigger keyup > keypress > change, and the change event will cause the value to be changed by createHandleHiddenInputChange ~

[DiegoAndai]

Looks good to me, nice work @mj12albert 😊

Three things:

• This requires a minor bump on the next release
• In the release notes, let's add a heads up about it and link to this PR
• In this PR's description PR, let's add an explanation of what can users expect with the change, for users that end up here from the release notes

[DiegoAndai]

@mj12albert I provided more detail in the description, feel free to correct anything I might've missed.

[mj12albert]

I provided more detail in the description

Thanks, looks good ~