Since the mobile web era began, web pages have included this #HTML boilerplate to indicate they've accounted for smartphone screens, so phones shouldn't zoom the #viewport weirdly:
The ideal viewport doesn’t exist:https://viewports.fyi/
You can’t make design decisions based on user’s viewport, instead, go beyond, structure your content, make sure it works at different sizes, with different user conditions, etc. #Responsive#Viewport
🟡🔵 The ideal viewport doesn’t exist
By Leanne Renard @leannecodes , Liridon Hasani liridon.dev and Andy Bell @belldotbz@andy , for Set Studios @setstudiotweets #viewport#css#webdev
This week I’m messing about with scroll-linked animations, and I’m having trouble figuring out a way to do a specific pattern. Easier to show it than to describe it, but I’ll try: The animation starts in its timeline according to how much of the element has been revealed, and proceeds from there to 100% as the end of the element approaches the view. In effect, “the furthest point in the element you can see is this much from the beginning of the element.” Any clever clogs care to cogitate?
@simevidas@kizu@Meyerweb I think what was meant is "when the viewport needs to scroll" instead of a literal interpretation.
In https://drafts.csswg.org/css2/#viewport it says “UAs for continuous media generally offer users a viewport [...] When the viewport is smaller than the area of the canvas on which the document is rendered, the UA should offer a scrolling mechanism”
This mechanism is not named in the spec but I've heard/used the terms root scroller or document scroller.
If that is true, then why does 100vw overflow when a classic scrollbar is present? Classic scrollbars shrink the ICB, so 100vw should decrease, but it doesn’t, so the spec text is wrong or what?
edit: The answer is that the CSS spec lives in an imaginary world where classic scrollbars don’t exist, so the ICB is never shrunk by such a scrollbar.