W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[css3-ui] controlling the orientation of progress/meter/range

From: Jonathan Kew <jfkthame@gmail.com>
Date: Thu, 26 Jun 2014 14:41:41 +0100
Message-ID: <53AC2315.6010504@gmail.com>
To: www-style list <www-style@w3.org>
There have been some previous discussions related to this, e.g. threads at:

http://lists.w3.org/Archives/Public/www-style/2011Apr/0386.html
http://lists.w3.org/Archives/Public/www-style/2013Mar/0365.html
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0268.html

but it's not clear to me that any definite conclusion was reached, and 
AFAICS nothing has appeared in either the HTML or CSS specs to resolve 
the issue. So I'd like to raise the question again, and see if we can 
move forward here.

By default, in Gecko we display <progress>, <meter> and <input 
type=range> elements as horizontal bars or sliders.

However, for <progress> and <meter>, we support a prefixed CSS property 
'-moz-orient', which may be set to 'vertical' to display a vertical 
progress bar or meter.

For <input type=range>, on the other hand, we support an HTML attribute 
'orient', which may similarly be set to 'vertical' to get a vertical 
slider control.

The HTML spec suggests that for <input type=range>, the UA could choose 
horizontal or vertical orientation depending on the relative 
height/width of the element. However, there seems to be general 
agreement that this isn't a good idea. (Does anyone currently implement 
this?)

There seem to be several rather unsatisfactory aspects to this at the 
moment:

* It's confusing for authors if <progress> and <meter> use one technique 
(CSS property) to control orientation, while <input type=range> uses 
another (HTML attribute, or possibly dimensions). From an author's point 
of view, these elements seem quite similar and should be expected to 
behave in similar ways. We should settle on one or the other - does this 
belong in HTML or in CSS? - and use it consistently.

* The default orientation of these elements should (IMO) be responsive 
to writing-mode. In a 'vertical-lr' or 'vertical-rl' document, I'd 
expect them to be displayed vertically by default. This should be 
addressed in the spec.

* Gecko's current property/attribute deals with the physical 
orientations 'horizontal' and 'vertical'. However, to be responsive to 
writing-mode, it would be more useful to have logical orientations 
'inline-axis' and 'block-axis', with 'inline-axis' being the initial value.

* Should there be both physical and logical values available? I'm 
inclined to think so; it seems reasonable to expect there may be use 
cases for both ways of specifying of behavior.

* How about specifying circular or "spinner" versions of these elements? 
It would seem natural to offer this as an additional display option.

So I'd like to propose - given that a number of people, in earlier 
discussions, seemed to think that a presentational attribute in HTML was 
not the appropriate solution - a CSS property 'orient' (or 
'orientation'?), something like this:

   Name: orient
   Value: inline-axis | block-axis | horizontal | vertical | circular
   Initial: inline-axis
   Applies to: <progress>, <meter> and <input type=range> elements
   Inherited: no (?)
   Media: visual
   Computed value: same as specified value (?)
   Percentages: n/a
   Animatable: no

Some open questions: should this property inherit? I'm guessing not; is 
that appropriate? Should its computed value equal the specified value, 
or should it resolve 'inline-axis' and 'block-axis' to one of the 
physical orientations, based on the value of writing-mode? Are there 
other elements where specifying orientation would be useful?

My initial suggestion would be that the computed value should simply be 
equal to the specified value, but I don't have a lot of experience with 
this stuff, so will happily defer to more expert opinions.

JK
Received on Thursday, 26 June 2014 13:42:02 UTC

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