When I finish the basic implementation of <input type=range> in bug 344618, it will do as the non-normative section text of the HTML 5 spec suggests and base the orientation of the slider (horizontal or vertical) on the ratio of the element's computed width/height. It would seem to make sense to allow -moz-orient to override this though, but we'll need to allow it to also accept the 'auto' value and make that its initial value in order to do that.

Jonathan, have you looked at <meter> and <progress> implementation? They are both implementing -moz-orient. IIRC, we are not exactly exactly following the spec: if you do not set -moz-orient, I do not think we use the widht/height ratio to guess it. The reason is because we have a pseudo-class to access vertical/horizontal elements but that pseudo-class could be used to change the height/width, putting us in an infinite loop.

The HTML 5 spec doesn't mention using the width/height ratio for <meter> or <progress>, and we just give them the horizontal orientation unless |-moz-orient:vertical| is used to override that. <input type=range> is different given that the spec does mention the width/height ratio thing, and other implementations use the width/height ratio to decide the orientation, and as a result content on the Web now relies on that. So I think we have to do the width/height ratio thing at least. I'm not aware of the existence of a pseudo-class to access vertical/horizontal elements. What is its name, and where is its documentation? You're not talking about box-orient are you?

Using -moz-orient sounds like a better idea than using the width/height ratio, I think.

David and I discussed this offline and agreed that, after adding an 'auto' value for -moz-orient and making that its initial value, the following would be sane: * if -moz-orient is not auto, use the orientation it specifies * else, if width is not auto and height is, make it horizontal * else, if height is not auto but width is, make it vertical * else, if neither width or height is auto, use the computed width to computed height ratio (a ratio >= 1 being horizontal, < 1 being vertical) * else (if both width and height are auto) make it horizontal This would allow content authors to get sane behavior when specifying only one of width/height with the intention of that value being the length of the slider, while allowing the other dimension to fall back to the slider's "natural" size.

(In reply to Jonathan Watt [:jwatt] from comment #4) > * else (if both width and height are auto) make it horizontal ... or, once we implement 'writing-mode', honor make it horizontal in horizontal text and vertical in vertical text.

I was completely wrong in comment 1 and what we implement is actually simply show a vertical progress bar if -moz-orient is set se 'vertical' and use default width/height accordingly if there are not set for the element. There is indeed no pseudo-class to catch orientation for elements and I'm not sure why. That could be interesting to have that though. I wonder if that would be technically doable.

Ah actually, one more thing. I think it would be better to have <meter>, <progress> and <input type='range'> to behave the same way regarding orientation. Whether we change <meter> and <progress> to use the <input type='range'> behaviour or we make <input type='range'> use the meter behaviour. I do not really have any strong opinion so I believe we sholud discuss this.

We decided some time ago that the whole auto-orientation thing based on computed size ratios was too magical and that we wouldn't do that. WONTFIX'ing.