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

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 13 Apr 2011 16:09:29 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2AC0148E@TK5EX14MBXC113.redmond.corp.microsoft.com>

[Boris Zbarsky:]
> On 4/12/11 6:14 PM, Tab Atkins Jr. wrote:
> > We (Chrome) also noted this issue and think it's a problem.  Not sure
> > what the right solution would be, unfortunately.  You want the
> > orientation to be separate from the width/height.  You don't want to
> > specify the orientation in the markup (as an attribute in HTML), as a
> > reactive design might change the slider orientation when the layout
> > changes, to better fill the new area.
> Or it might not.
> The current spec _forces_ the orientation to change.  That doesn't seem
> like a good idea.
> An attribute could be modified via script as a last-ditch fallback to deal
> with layout changes (though that might take UAs implementing onresize
> support on random elements).
> > The only think I can think of that would work properly is a
> > slider-specific CSS property that specifies the orientation.
> How would this be better than an attribute in the markup?  I feel like I'm
> missing something.

Me too. Having a property does not address the 'select sliders/meters with 
orientation X' scenario. Which may be useful for default UA stylesheets and 
authors alike. If you use a property to orient the slider track then WebKit's 
duplicate horizontal/vertical pseudo-elements make sense. Duplicating all 
control parts to address orientation feels heavy, author-unfriendly and 
all around hard to maintain though. 

Received on Wednesday, 13 April 2011 16:10:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC