- 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>
[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