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

On 04/12/2011 04:00 PM, Sylvain Galineau wrote:
> 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.

For the moment, we (Mozilla) might not do the automatic reorientation 
requested by HTML specifications because it's not obvious that 
reorienting depending on width and height is always a good idea [1]. 
Though, we might add a 'orient' attribute to let authors specify the 
orientation of the element. For the moment, it would be 
horizontal/vertical but it could be more complex to handle other situations.

[1] If width and height are percentage values, the orientation might 
change depending on the window's size for example.

--
Mounir

Received on Wednesday, 13 April 2011 00:27:38 UTC