W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: Allowing content authors to get vertical <input type=range>

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 20 Mar 2013 15:28:28 -0700
Message-ID: <CAAWBYDCqEx16OznqrV45Lf68rSO04WdY3McsJP8zyvQeRsAKZA@mail.gmail.com>
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

However, that wont' be something quick to do.  I recommend an orient
attribute for now.

Received on Wednesday, 20 March 2013 22:29:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:09 UTC