Rendering <input type=range> vertically

@zcorpan

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

Note the disadvantage of using a CSS property that I brought up in an email to www-style back in 2013.

(And discussion in the Mozilla bug to decide how to handle orientation.)

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.

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.

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.

That sounds like a Blink limitation, unless a vertical range control requires a different shadow tree structure.

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.

I'm not sure we should be designing more magic, un-implementable-using-web-developer-exposed-technologies, abilities into the built-in form controls.

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.

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.

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.

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.

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.

@yisibl

@yisibl can't you override individual controls using writing-mode directly on them?

@yisibl

@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.

@andreubotella

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)

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.

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.

Redefine progress, meter, and range input's layout

Navigation Menu

Repository navigation

Rendering <input type=range> vertically #4177

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Rendering <input type=range> vertically #4177

Description

Activity

jwatt commented on Nov 15, 2018

jwatt commented on Nov 15, 2018

MatsPalmgren commented on Nov 15, 2018

tkent-google commented on Nov 19, 2018

MatsPalmgren commented on Jan 25, 2019

annevk commented on Jan 28, 2019

tkent-google commented on Jan 28, 2019

domenic commented on Jan 28, 2019

tabatkins commented on Jan 29, 2019

tkent-google commented on Feb 4, 2019

tkent-google commented on Jan 27, 2020

dizhang168 commented on Jan 3, 2024

yisibl commented on Jan 9, 2024

annevk commented on Jan 9, 2024

yisibl commented on Jan 9, 2024

yisibl commented on Jan 9, 2024

yisibl commented on Jan 18, 2024

yisibl commented on Jan 18, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions