![]() If any of these were the case, the element wouldn’t pin itself to the bottom at all - it would just sit where I put it. There are lots of reasons why position: sticky can fail to work. Position issue when toolbar hides Investigation In Chrome it was “1 toolbar above the bottom” as Chrome only has one toolbar.īasically, the change in height was not spotted by the positioning of the element sticking to the bottom. In Edge, when the two toolbars were removed, the position of the element was “2 toolbars above the bottom”. However, on my real phone it had an issue when the browser toolbars are removed (this tends to happen once you start scrolling down pages as it gives the content more space). The element sticky to the bottom until you “scroll past it” in the document, at which point in then joins the normal document. It even worked as expected on Lambdatest’s real-time testing. Using responsive test tools in my browser, everything worked fine. It is set up to stick to the bottom of the viewport.The removal of tool bars on mobile is a long-running fiasco, soon to be solved by the addition of a new set of viewport units. height: 100vh is so close to greatness, but given it’s limitations on mobile it’s best to avoid it.There is a strange CSS positioning issue I found on mobile browsers when the address bar is removed. It’s a shame there’s still not an easy way to get an element to take up the full viewport height without relying on javascript. ![]() Furthermore, by locking the height in place when the page first loads, it prevents the address bar from hiding in the middle of using the site thus creating an awkward screen resizing experience. The screen will be the height of the viewport regardless of whether or not the address bar is visible. For example, try opening wordsheet.io/demo/V3Y on a mobile browser. You can see this in action when studying on Wordsheet.io. If the address bar is hidden, then window.innerHeight will be the height of just the visible portion of the screen, as you’d expect. If the address bar is visible, then window.innerHeight will be the height of the full screen. When the page loads, setting the height to window.innerHeight will correctly set the height to the visible portion of the window. One way to get around this issue is to rely on javascript instead of css. Worse, when a user first goes to a website on mobile the address bar will be visible at the top, so the broken experience is the default experience. In the image above, the button which should be at the bottom of the screen is instead hidden. When the address bar is visible, the bottom of the screen gets cut off since mobile browsers incorrectly set 100vh to be the height of the screen without the address bar showing. The result is that the bottom portion of the screen will be cut off when the address bar is visible, thus defeating the purpose of 100vh to begin with. Rather than adjusting the height of 100vh to be the visible portion of the screen as the viewport height changes, these browsers instead have 100vh set to the height of the browser with address the address bar hidden. The core issue is that mobile browsers (I’m looking at you, Chrome and Safari) have a “helpful” feature where the address bar is sometimes visible and sometimes hidden, changing the visible size of the viewport. It’s best to avoid 100vh and instead rely on javascript to set heights for a full viewport experience. 100vh is broken in a subtle but fundamental way on mobile browsers that makes it nearly useless. If you want to style an element to take up the full screen height, you can just set height: 100vh and voila - you have a perfect fullscreen element, which resizes as the viewport changes! Sadly, this is not the case.
0 Comments
Leave a Reply. |