- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Tue, 12 Apr 2011 23:00:44 +0000
- To: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <045A765940533D4CA4933A4A7E32597E2AC00FF7@TK5EX14MBXC113.redmond.corp.microsoft.>
The current HTML5 specification suggest using the specified width and height of specific form controls to define the orientation of the control for the end user. For instance, for the range control (typically represented as a slider), we have [1]: # Note how the UA determined the orientation of the control from the ratio # of the style-sheet-specified height and width properties. Later, it says more normatively [2]: # When the control is wider than it is tall (or square), the control is expected to be a horizontal slider, with the lowest value on the right if the 'direction' # property on this element has a computed value of 'rtl', # and on the left # otherwise. When the control is taller than it is wide, it is expected to be a # vertical slider, with the lowest value on the bottom. Opera currently supports this behavior. A first issue is that one cannot have a square or flat slider that slides vertically. This is not an obvious issue with the basic design showed in the spec but could be a problem when CSS allows the author to style the control e.g. by using a custom background. For instance, imagine the vertical equivalent to this design, possibly with marks on both sides of the track: http://www.filebuzz.com/software_screenshot/full/volcon_options_general.png (I am also attaching a simple mockup showing a vertical design with a horizontal aspect ratio). Then, if a slider can be styled, the author may need different rules for each orientation. She can certainly create two classes, one for vertical, one for horizontal. A browser's default stylesheet couldn't really do that, however. And isn't it the same progress bar or slider style whether it's vertical or horizontal ? Shouldn't they both use the same class ? Some options that come to mind: 1. A pseudo-class (:horizontal/:vertical): while there certainly are precedents for post-layout pseudo-classes (:first-line) I assume this is a non-starter as the rule can update width/height and cause a loop. 2. An HTML attribute ? This certainly can be selected but it doesn't seem appropriate to add a presentational attribute to solve the problem. 3. Vertical and horizontal sets of pseudo-elements to style the control, as proposed on this WebKit wiki page [3] as well as a property to switch from vertical to horizontal. The multiplication of pseudo-elements seems heavy and implies a change in orientation also requires a rewrite of the relevant selectors. I'd love to hear how others think this kind of scenario should be resolved. [1] http://www.w3.org/TR/html5/number-state.html#range-state [2] http://www.w3.org/TR/html5/rendering.html#the-input-element-as-a-range-control [3] http://trac.webkit.org/wiki/Styling%20Form%20Controls
Attachments
- image/png attachment: custom-slider.png
Received on Tuesday, 12 April 2011 23:04:15 UTC