That means we will want to apply it in our CSS like this. Let’s say our CSS custom variable is -vh for this example.
The trick is to store the viewport value in a CSS variable and apply that to the element instead of the vh unit. This value takes the browser’s interface into account and is updated when its visibility changes. In JavaScript, you can always get the value of the current viewport by using the global variable window.innerHeight. The idea struck me that CSS Custom Properties and a few lines of JavaScript might be the perfect way to get the consistent and correct sizing I needed. CSS Custom Properties: The trick to correct sizing An element gets cropped at the bottom when the address bar is in view (left) but what we want is the full thing (right). The bottom of your element will be cropped. While using a fixed value is nice, it also means that you cannot have a full-height element if the address bar is in view. Chrome’s mobile browser followed suit around a year ago.Īs of this writing, there is a ticket to address this in Firefox Android. By doing so, the user would not experience jumps on the page once the address bar went out of view. Safari for iOS was one of the first mobile browsers to update their implementation by choosing to define a fixed value for the vh based on the maximum height of the screen. Once you get past a piece of the browser interface, like the address bar, the vh value would update and the result was an awkward jump in the content. If you opened your browser and started to load a website, 1vh was equal to 1% of your screen height, minus the browser interface.īut! If you start scrolling, it’s a different story.
Vh was initially calculated by the current viewport of your browser. So yeah, no clear guidance there when it comes to handling device and browser-specific differentiations. With mobile devices, we’re often concerned with the vertical height, so let’s look specifically at viewport height ( vh):Įqual to 1% of the height of the initial containing block. The spec is pretty vague about how viewport units should be calculated. Viewport units have always been controversial and some of that is because of how mobile browsers have made things more complicated by having their own opinions about how to implement them.Ĭase in point: should the scrollbar be taken into account for the vw unit? What about a site’s navigation or page controls - should those count in the calculation? Then there are physical attributes of the devices themselves (hello, notch!) that can’t be overlooked.
0 kommentar(er)
