Re: [csswg-drafts] New property to control the direction of slider controls (#9832)

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

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9832#issuecomment-2770518264 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 1 April 2025 19:45:38 UTC