Html: Rendering <input type=range> vertically

[MatsPalmgren]

The 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:

1. 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.
2. 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

[jwatt]

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

[jwatt]

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

[MatsPalmgren]

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.

[tkent-google]

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.

[MatsPalmgren]

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]

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

[tkent-google]

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]

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]

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]

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.

[tkent-google]

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.