GeezerVison is showing github.com — Rendering <input type=range> vertically · Issue #4177 · whatwg/html
Rendering <input type=range> vertically #4177DescriptionThe Rendering section suggests that:
When the control is taller than it is wide, it is expected to be a vertical slider
This is bad for a few reasons:
- it forces the style sheet author to specify an explicit definite
width/height of the control. This is bad since the intrinsic size of this element varies between platforms and is affected by the user's native theme, so it cannot be known in advance by the style sheet author. Specifying definite sizes are bad in general since they don't work well if the user has set a non-default preferred font-size in their Preferences.
- there is a use case for having a vertical control that is in fact wider than it's tall due to having very long
<option label> text. This use case can't be supported if the control magically switches to horizontal layout when that happens.
There needs to be a way for authors to request a vertical/horizontal control and still have it intrinsically sized. Authors currently do that in incompatible ways for each UA. This note summarizes the problems with current solutions:
https://css-tricks.com/sliding-nightmare-understanding-range-input/#orientation
Using CSS transform or writing-mode for this is bad since a vertical control may not have the same appearance as a rotated horizontal control. It also rotates the label text which is undesirable. The Blink/WebKit solution to have different -webkit-appearance value (slider-vertical) is also bad since it prevents the author from applying custom styling to a vertical control (you generally want -webkit-appearance:none for that). The Gecko solution of using a orient attribute is not good since this is something that should be controlled by CSS.
I think we need to standardize something that works in all UAs without those problems.
I propose that <input type=range> should have -webkit-appearance:range in the UA sheet for both horizontal and vertical controls and that we introduce a new CSS property to control the orientation,
e.g. orientation: horizontal | vertical | inline-axis | block-axis.
CC @zcorpan @tkent-google @jwatt Reacted by ExE Boss, Brad Isbell, Sébastien Règne, Ivan Gilchrist, Allan Bonadio, Yisi, 严文彬 and Ana Tudor Activityjwatt commented on Nov 15, 2018 Note the disadvantage of using a CSS property that I brought up in an email to www-style back in 2013. jwatt commented on Nov 15, 2018 (And discussion in the Mozilla bug to decide how to handle orientation.) MatsPalmgren commented on Nov 15, 2018 You mean the disadvantage that authors can't use "[orient=vertical]" as a selector?
That seems like a non-issue if the orientation is specified in CSS by the author since presumably they already have a relevant selector for those elements. CSS is better since this is a rendering concern and it allows you to easily switch between horizontal/vertical layout based on media queries etc. Still, I guess we could have a HTML attribute too and simply attribute-map it to the CSS property. I just don't think it's needed. Reacted by ExE Boss and Yisi tkent-google commented on Nov 19, 2018 I agree that ratio of width/height is a bad idea, and -webkti-appearance:slider-vertical is also a bad idea.
I'd be happy if UA can detect orientation with DOM level information such as content attribute because the current range implementation in Blink uses shadow nodes and updating shadow nodes style depending on the host style needs a hack. Reacted by Masataka Yakura, Domenic Denicola and ExE Boss MatsPalmgren commented on Jan 25, 2019
I'd be happy if UA can detect orientation with DOM level information such as content attribute because the current range implementation in Blink uses shadow nodes and updating shadow nodes style depending on the host style needs a hack.
Is that just an implementation issue in Blink or is it a more fundamental design error in Shadow DOM? It seems kind of sad to me if Shadow DOM implies that we're going back to styling things using HTML attributes instead of CSS. annevk commented on Jan 28, 2019 That sounds like a Blink limitation, unless a vertical range control requires a different shadow tree structure. tkent-google commented on Jan 28, 2019 It's an implementation issue of WebKit and Blink.
CSS property like orientation is acceptable. It would be implementable in WebKit and Blink though we might need some time to implement it. domenic commented on Jan 28, 2019 I'm not sure we should be designing more magic, un-implementable-using-web-developer-exposed-technologies, abilities into the built-in form controls. tabatkins commented on Jan 29, 2019 Yeah, lack of CSS-listeners is what's really hurting this. You can listen for attribute changes and respond accordingly; all you can do for CSS is poll. tkent-google commented on Feb 4, 2019 Another wild idea is just dropping the vertical rendering from the specification.
I have never seen <input type=range> is used for form submission in real web sites, and the current capability of Custom Elements API would be enough. Reacted by Brad Isbell, Cassie Jones, Frank Holtmann and Yisi tkent-google commented on Jan 27, 2020 I wrote:
I'd be happy if UA can detect orientation with DOM level information such as content attribute because the current range implementation in Blink uses shadow nodes and updating shadow nodes style depending on the host style needs a hack.
I had some local experiments. If the orientation just follow the writing-mode property, it would work very well. WebKit/Blink implementations don't need to change shadow node structure/style for the writing-mode value. dizhang168 commented on Jan 3, 2024 Vertical <input type=range> should behave similarly to vertical <meter> and <progress elements. Given the conversation in #8413 and the feedback from i18n folks, we should encourage rendering of vertical ranges using writing-mode and use direction to determinate the direction of the value. yisibl commented on Jan 9, 2024
Vertical <input type=range> should behave similarly to vertical <meter> and <progress elements. Given the conversation in #8413 and the feedback from i18n folks, we should encourage rendering of vertical ranges using writing-mode and use direction to determinate the direction of the value.
We can set the default direction of the progress bar for different writing-mode and direction, which is fine. However, controlling the direction individually through the new CSS properties will result in better ergonomics.
For example, I'm a Chinese user, and in vertical-rl, although the text is written from top to bottom, it doesn't necessarily mean that my progress bar has to be from top to bottom. Besides, sometimes a vertical progress bar is needed when writing horizontally.
Imagine there's a thermometer on the page 🌡 I would prefer bottom to top. Reacted by 严文彬 and liruifengv Reacted by liruifengv annevk commented on Jan 9, 2024 @yisibl can't you override individual controls using writing-mode directly on them? yisibl commented on Jan 9, 2024
@yisibl can't you override individual controls using writing-mode directly on them?
@annevk Considering that input ranges often have a tooltip, I don't want the text direction of the tooltip to change when adding:
input[type="range"] {
writing-mode: vertical-lr;
}
::-webkit-slider-thumb {
anchor-name: --thumb;
}
input[type="range"]::after {
content: attr(data-value);
position: fixed;
anchor-default: --thumb;
left: anchor(center);
top: auto;
bottom: calc(anchor(auto) + 5px);
translate: -50% 0;
}So I think the direction of the progress bar should not be coupled with the writing-mode.
Reacted by Yisi, 快乐的小萌新, Orion Chen, chenchangyu, 严文彬, Lea Verou, Wei Zhu and Sébastien Règne yisibl commented on Jan 9, 2024
The direction CSS property isn't meant to change the direction of a progress bar, but to change the direction of the inline progression of text, meant to be used for languages that are written right-to-left such as Hebrew and Arabic. Changing the direction of the progress bar is a side effect, that I don't think is a good practice. And in cases such as writing sideways RTL languages in vertical text, the direction property can still be used (where "left" maps to top and "right" to bottom).
I quote and agree with @andreubotella #8413 (comment) yisibl commented on Jan 18, 2024 The HTML specification is confusing in its description of vertical rendering, and in any case, I think the specification should be updated as soon as possible, as said here again:
Note how the UA determined the orientation of the control from the ratio of the style-sheet-specified height and width properties.
yisibl commented on Jan 18, 2024 There is a wide demand for a vertical input range community:
Vertical input ranges are also very common in cell phone operating systems. For example, iOS:
The confusion of the specification brings poor interoperability and we need to reach a consensus as soon as possible. I prefer having a CSS property to control direction. Reacted by 严文彬, Adam Argyle, Ivan Gilchrist and ashah7 added a commit that references this issue on Mar 4, 2024This issue will close once commit 702119c is merged into the 'main' branch.702119c added a commit that references this issue on Mar 10, 2025This issue will close once commit 706c356 is merged into the 'main' branch.706c356
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
