Add a new media query feature: client-width and client-height, which equal to (viewport size - scrollbar size)

[Zhang-Junzhi]

Please consider adding two new media query features: client-width and client-height

which equal to the viewport size if there's no scrollbar;
or equal to (viewport size - scrollbar size) if there's a scrollbar.

client-width, client-height are very useful, they are even more useful than the existing width, height features.

Designers typically tend to care more about the available layout size than the size including a scrollbar

[jonjohnjohnson]

#1766

[Zhang-Junzhi]

Thanks for the info, @jonjohnjohnson

#1766 seems an issue regarding whether to substract the scrollbar size in vw, vh when the computed value of overflow is scroll, and you mentioned css-scrollbars, which is helpful if a page always overflows in a direction.

Right now my use case is designing a page which doesn't overflow in a normal fullscreen but can overflow if the user shrinks the window, and I also need a precise size for layout.

[Zhang-Junzhi]

I didn't think of why the two features weren't added in the first place, after a thought today, I kind of understand the reason behind it.

May it be a consideration of a paradox? The paradox is:
If we don't do layout, how can we know if it overflows beforehand? If we don't know if it overflows beforehand, how can we provide the client width/height beforehand for layout to use? Although in theory by doing layout twice we can get an unambiguous answer in almost cases except some really-rare corner cases, it just isn't worth of it.

[tabatkins]

Yup, exactly. And further, you can adjust the overflow value based on a MQ, so you could get into styling loops with this where you apply overflow:scroll if the page is above a certain size, and switch to overflow:hidden when it's below that, and cycle back and forth as the scrollbars appear, shrink the page's size, then disappear.

[Zhang-Junzhi]

Thanks for the clarification. @tabatkins

[coreyworrell]

@tabatkins This probably isn't the right place for this, but I've never understood this attitude of not writing specs/features because of possibility of styling loops. If people want to write stupid code then let them write stupid code. JavaScript is open to endless loops, but specs/browsers don't prevent you from running them whether on accident or not.

[frivoal]

@coreyworrell loops in css and loops in js are different beasts. Js is an imperative language, so if you follow an bunch of steps, and then need to start again, and repeat forever, it may be stupid, but at least it is clear what that means. CSS is a declarative language, which describes the results, not the step to get there. The kind of loop we're talking here are circular logic and internal contradictions, not infinitely repeating steps. It's not stupid code as JS loops could be, it's meanignless / ambiguous / self-contradictory code, which browsers couldn't possibly implement, because nobody knows what it is supposed to mean.

[coreyworrell]

@frivoal Thanks for reply. I understand the difference and what loops we're talking about here. Circular logic and internal contradictions created by the author. If I have circular logic it is my own fault, not the browsers.

The rest of my reply I added to #1766 (comment) as it seems to fit there better.