New property to control the direction of slider controls

[mfreed7]

I'm extracting this question from the various discussions in several forums:

• [css-pseudo-4] Standardizing input[type="range"] styling #4410 (comment)
• Rendering <input type=range> vertically whatwg/html#4177 (comment)
• Clarify value direction for elements "progress" and "meter" with vertical writing mode whatwg/html#8413 (comment)
• [switch]: Should author defined content be allowed on tracks or thumb? openui/open-ui#959

For slider controls (<input type=range>, <progress>, <meter>, potentially <input type=checkbox switch>, etc.) there is a desire to be able to control:

1. The orientation of the slider: horizontal vs. vertical.
2. The polarity/direction of the slider: which way is toward "more".
3. The writing mode and direction of any text associated with the control, such as tooltips.

In current browsers, #1 is controlled by the CSS writing-mode property, and #2 is controlled by the CSS direction property. This does allow full control of orientation and direction for sliders, and at least recently (thanks @dizhang168), this behavior is implemented interoperably, despite a lack of standards for this behavior. However, because of #3 (see whatwg/html#4177 (comment) in particular), it might make sense to have a specific CSS property to control the orientation and direction of slider type controls. One tricky detail will be getting it to behave predictably in the face of existing writing-mode/direction behavior, and maybe even the non-standard orient=vertical.

[yisibl]

Placeholders.

I will add a detailed proposal here later.

[annevk]

Given that https://w3c.github.io/aria/#aria-orientation exists I wonder to what extent we should consider this to be a presentational aspect of the control. Maybe orient=vertical is the right approach?

[tabatkins]

I'm curious what value knowing the orientation in ARIA brings.

---

I agree that (ab)using writing-mode and direction for this is pretty hacky. We really should just add a dedicated property for it instead; those writing orientation properties have side effects we don't really want to invoke.

Quick proposal:

slider-orientation: [ inline | block | self-inline | self-block ]
                 || [ start | end | self-start | self-end ]

• First value controls whether it's aligned with the inline axis ("horizontal") or block axis ("vertical"). Per usual for these sorts of values, plain values are relative to the containing block's writing-mode, self-* are relative to the element's own writing-mode.
• Second value sets whether the "low" value is toward the start side of that axis, or the end side. Again, plain values use the containing block's direction, self-* use the element's own direction.

If we give it an initial value of self-inline self-start, this'll automatically play nicely with the existing writing-mode/direction hacks, I believe, and in the default case (where you aren't setting either of those properties) will correctly give a horizontal slider with the low value toward the left (in English). You can also override that to, say, inline start, and then use writing-mode/direction to change how the text in it renders without affecting the slider itself.

[annevk]

I discussed this with some colleagues and one of them shared this insight:

VoiceOver will announce the orientation of controls when you land on them (if you want an example, feel free to try out the sliders on this page). Imo, vertical vs horizontal sliders can have implicit meanings (think: volume bar that goes from bottom to top, 0 to 100 ), vs a horizontal slider that may be used to pick a point on a spectrum between two things in opposition.

That indicates this is a semantic aspect of the control and thus should be controlled by HTML.