Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Zhang-Junzhi opened this issue Jul 17, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@Zhang-Junzhi
Copy link
Contributor

commented Jul 17, 2018

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

@Zhang-Junzhi Zhang-Junzhi changed the title Add a new media query feature: client-width and client-height, which equal (viewport size - scrollbar size) Add a new media query feature: client-width and client-height, which equal to (viewport size - scrollbar size) Jul 17, 2018

@jonjohnjohnson

This comment has been minimized.

Copy link

commented Jul 17, 2018

@Zhang-Junzhi

This comment has been minimized.

Copy link
Contributor Author

commented Jul 17, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 18, 2018

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

This comment has been minimized.

Copy link
Member

commented Jul 19, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 20, 2018

Thanks for the clarification. @tabatkins

@coreyworrell

This comment has been minimized.

Copy link

commented Feb 4, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Feb 4, 2019

@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

This comment has been minimized.

Copy link

commented Feb 5, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.