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.

[css-meeting-bot]

The CSS Working Group just discussed New property to control the direction of slider controls.

The full IRC log of that discussion

<fantasai> ntim: input[type=range], meter, progress, switch all currently follow writing mode and text direction
<fantasai> ntim: If you're in vertical writing mode, it will be vertical and the text direction specifies whether goes top to bottom or bottom to top
<fantasai> ntim: Desire to make this independent of the writing-mode and text direction, because in some cases you want the direction of the slider to be physical rather than logical
<fantasai> ntim: For example, temperature. Classically increase bottom to top. Not dependent on writing mode.
<fantasai> ntim: There's an existing proposal on the draft for a property called `slider-orientation` with some values
<fantasai> ntim: 'auto' for using text direction, and some physical values.
<fantasai> ntim: not sure if that's the right design, so wanted to ask for input
<astearns> ack fantasai
<lea> q?
<TabAtkins> fantasai: i think there's two fundemantel question
<TabAtkins> fantasai: one question is what values to give this properity
<TabAtkins> fantasai: but more fundamental, how is this interacting with the styling of the elements within the slider
<lea> q+ if we create a new property, this is much broader than sliders
<TabAtkins> fantasai: we've ahd fairly simple interactions, like appearance with display
<lea> q+
<TabAtkins> fantasai: it's a realtively straightforward mapping
<bkardell> q+
<TabAtkins> fantasai: but this would ahve to change padding/etc, a lot of properties, based on the value on the slider
<TabAtkins> fantasai: so it's a lot more complicated
<TabAtkins> fantasai: than we get on previous things
<TabAtkins> fantasai: so what's the mechanism by which this works, and is that a mechanism we want to adopt?
<TabAtkins> fantasai: if yes, then slider control orientation would need a bunch of values. id' suggest both physical and logical values
<TabAtkins> fantasai: we can come up with a set of keywords, that's not a problem
<astearns> ack lea
<fantasai> lea: I don't have an opinion yet about whether to introduce a new property.
<fantasai> lea: but if we do, this is a lot broader than slider. This problem comes up with many elements.
<fantasai> lea: e.g. selects. can have a select list that's horizontal.
<fantasai> lea: But mainly this comes up a lot in components. Very common to have a component with both horizontal and vertical orientation options
<astearns> ack bkardell
<fantasai> lea: so if we have this property, can we make it more generic than sliders?
<fantasai> bkardell: Any thoughts on Anne's comment about whether this belongs in HTML?
<fantasai> dbaron: I think some of it is presentation. Or at least associated with direction and writing mode
<fantasai> dbaron: at least it seems that way
<astearns> ack fantasai
<dbaron> s/some/at least some/
<TabAtkins> fantasai: I think a lot of hte use-cases dictating the direction are presentational
<TabAtkins> I agree
<TabAtkins> and other aspects of semantics do come from CSS at times
<ntim> q+
<fantasai> astearns: Can the presentational aspects be overridden using existing properties, or do we need a new property for this kind of switching behavior?
<astearns> ack ntim
<fantasai> ntim: Elika's question about existing margins/paddings/etc. as we change orientations makes a lot of sense
<fantasai> ntim: One thought is maybe we should have a shorthand for writing-mode and direction?
<fantasai> fantasai: No, we don't want to do that.
<TabAtkins> fantasai: we used to have that and got rid of it, because it's a bad idea
<fantasai> (This is because writing-mode is presentation, and direction is content description)
<TabAtkins> ntim: so the new property we come up with, shoudl it affect the ocmputation of th elogical properties?
<fantasai> ntim: Or should we have some other mechanism?
<bkardell> s/ th elogical / the logical
<TabAtkins> fantasai: it's not just margins and paddings, it's width, flex-direction, etc
<TabAtkins> fantasai: we need to define the internal layout details, and slider orientation would change all of these
<TabAtkins> fantasai: in some cases we don't have physical equivalents, like flex is always logical
<TabAtkins> fantasai: it's complex
<fantasai> s/complex/complex to map from a slider-orientation value to e.g. flex-direction/
<fantasai> astearns: I'm hearing a lot more questions than answers, let's take back to the issue