W3C home > Mailing lists > Public > www-style@w3.org > April 2011

[css3-ui][html5] Form control orientation and styling

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.com>
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




custom-slider.png
(image/png attachment: custom-slider.png)

Received on Tuesday, 12 April 2011 23:04:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT