Re: [css3-meadiaqueries] Proposal for "content-width" and "content-height" media features

On Mon, Sep 9, 2013 at 2:47 AM, Robert Koritnik
<robert.koritnik@gmail.com> wrote:
> To whom it may concern
>
> Current W3C Recommendation document about CSS3 media queries defines width
> (and height) and device-width (and device-height) media features. Let's
> focused on the former and see why it's problematic and how it could be
> solved.
>
> The problem
> Width and height ("these" from now on) media features gives responsive web
> designers/developers the possibility to adjust content to available space.
> The problem is they don't get pixel-accurate control as these media features
> also include scrollbars which can vastly differ in their size over different
> browsers and operating systems. Touch devices usually don't even display a
> permanent scrollbar on scrollable content. All these differences mean that
> there is no reliable to efficiently control the amount of available space to
> designers/developers. The usual approach to applying media queries is to
> apply some safety space which can be occupied by a scrollbar when displayed.
> This means that for non-fluid layout we can't use the whole space which
> becomes even more apparent when there're no scrollbars as on touch devices
> that usually already have less space to start with.
>
> The proposed solution
> I would like to propose additional media features content-width and
> content-height that only account for actual available space not including
> scrollbars when they're displayed on root element. This would give
> designers/developers exact control of available space and they could use it
> accurately down to a single pixel. As scrollbars would be excluded from
> these values it would make it browser and OS independent and always correct.
>
> Example
> This is an example of a CSS media query:
>
> @media screen and (max-content-width: 320px) {
>     ...
> }
>
>
> Alternative solution
> As W3C Recommendation describes, media queries syntax could include complex
> expressions:
>>
>> Properties may accept more complex values, e.g., calculations that involve
>> several other values.
>
>
> If there was additional media feature scrollbar-width (and scrollbar-height)
> available content space could as well be accurately calculated.

Media features can't depend on the contents of the document (in
particular, they can't depend on whether the content is tall enough to
trigger a scrollbar), so at best these could give you the width/height
of the document *always minus the scrollbars*.  That is, you'd better
use overflow:scroll on the <body> if you want to use these MQs.

Further, several browsers (IE/WebKit/Blink) let you style scrollbars,
including the width.  Again, since MQs can't depend on page styling,
this would mean that it would have to subtract the *initial* size of
the scrollbars, before any customization muddled things.  (This is
similar to how the 'em' unit in MQs is resolved against the default
font size, rather than any font size specified in the document.)

Given these restrictions, though, the feature would be possible.  How
necessary is it, though?  If you find yourself needing pixel-perfect
control over when the MQ is satisfied, there's a good chance you're
doing something wrong - just define natural breakpoints when your page
layout starts to break down; these are always pretty forgiving, with a
good amount of space within which it would be valid to use either
layout.

Plus, as Kenneth said, overlay scrollbars are honestly the way to go
in the future.  I know we're experimenting with using them
cross-platform in Blink, because scrollbars are so terrible (they
cause us to have to redo layout when we determine that scrollbars are
necessary, doubling the layout time on lots of pages).  Having
scrollbars that don't take up any space will be a huge improvement.

~TJ

Received on Wednesday, 9 October 2013 18:10:05 UTC