- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 20 Mar 2013 15:28:28 -0700
- To: Jonathan Watt <jwatt@jwatt.org>
- Cc: www-style list <www-style@w3.org>
On Wed, Mar 20, 2013 at 1:11 PM, Jonathan Watt <jwatt@jwatt.org> wrote: > I'm working on <input type=range> support in Mozilla, and one of the > questions that has come up is how best to allow content authors to change > the orientation of <input type=range> to be vertical (so the slider runs > up/down instead of left/right). > > There is some vague text in the HTML5 spec describing an <input type=range> > example that hints that a UA might change a range's orientation based on the > ratio of its width to height[1], which says: > > Note how the UA determined the orientation of the control from the > ratio of the style-sheet-specified height and width properties. > > As far as I can tell that's all that any relevant specifications say on the > matter though. > > This issue becomes tricky when user agents provide pseudo-elements to allow > content authors to style the component parts of a range. Typically there are > two main component parts: the thumb (the bit that can be dragged left/right > or up/down) and the track (a visual "gutter" or "line" that the thumb is > fixed to move along). > > It seems like, A), it would be desirable to be able to apply different > styles to the thumb and track depending on whether the range is horizontal > or vertical. For example, content authors might want to give the thumb a > background image that would make it appear like one of the following two > diagrams depending on its orientation: > > | | > | | > __ | | > / \ _|_|_ > ----------| |-------- | \ > ----------| |-------- |_____/ > |__| | | > | | > | | > | | > > It also seems like, B), it would be desirable to be able to use CSS to > specify the orientation of the range, since, to a certain extent, whether > the range is vertical or not is a matter or presentation. > > Unfortunately, B (specifying the orientation using a new CSS property called > 'orient', say) seem to conflict with A. Content author's don't have a way to > select on the computed value of one property to specify the values of other > properties, so they can't select on the computed value of an 'orient' > property to specify different styling for horizontal/vertical range. > > One way to solve the issue would be to reject B and have an 'orient' > _attribute_ instead, since it _is_ possible to select on attributes. > > It may seem tempting to say that if content authors are specifying different > styles for vertical and horizontal range, then they can specify those styles > in the same rules that specify the 'orient' property. It doesn't seem like > that is going to provide for authors' needs in some circumstances though. > For example, if a JavaScript library provides API to insert a "vertical > range", and it specifies style="orient:vertical" on the range that it > inserts. > > Does anyone have any thoughts on the mechanism that should be provided to > content authors to specify that an <input type=range> should be vertical, > given the above? > > 1. > http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29 This is begging for the "element queries" thing that people keep asking for, and I keep shooting down. ^_^ However, it's actually a perfect spot for the restricted form that François has talked about where, if you can make an element replaced-like (so that its intrinsic size doesn't depend on its contents), you *could* actually use an element query focusing on that element. However, that wont' be something quick to do. I recommend an orient attribute for now. ~TJ
Received on Wednesday, 20 March 2013 22:29:15 UTC