AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Js: // Get the viewport height and multiply it by 1% to get a value for a vh unit Height: 100vh /* This is for browsers that don't support custom properties */ That is your problem.and say goodbye to it, because. Having the fixed value is awesome, except when you wanna have a full sized element, or an element with fixed position at the bottom of the screen because then it would get cropped out! Then the user wouldn't experience the jump in content, but. They set a fixed vh value based on the max screen height. Safari for iOS was actually was one of the first to implement a fix. Once you brush past the browser interface (in this case your address bar), you would have a weird jump in your content because the vh would be updated. If you loaded a site in your browser, 1vh would be the same as 1% of your screen height, and then minus the browser interface.īut! If you wanted to scroll, it gets tricky. Vh used to be calculated by the current viewport of your browser. Alas all those hours of misery have been for this moment. Hello this question kind of got me at first and I thought back to my days poking around in HTML and CSS for hours on end trying to get things right. Does anybody out there have any idea what is happening? Anybody aware of any workarounds? Anybody aware of an actual solution? It absolutely sucks that a website has to sometimes look like crap for the sake of user-experience due to this bug. I'm also worried that it might cause other issues on other devices in other browser that I'm unable to test. However, I just noticed that it creates an invisible vertical overflow and thus unnecessary vertical scrolling in at least Safari and Chrome. elements must create vertical overflow -> It's a super hack-ish workaround, and a crappy workaround at that, but it's the only thing so far that causes position: fixed bottom: 0 to actually position an element at the bottom of the viewport after switching orientations if there is no overflow. What's interesting is that the height of the navigation bar in landscape mode clearly offsets the viewport so that position of bottom: 0 or top: 100% is pushed outside of the viewport when the navigation bar is being displayed. The navigation bar is only ever hidden in landscape mode due to downward scrolling or orientation change from portrait to landscape. The issue with landscape mode always and only occurs when the normal navigation bar is displayed at the top of the page. I'm not sure exactly what's happening here. Notably, the condensed menu bar is only ever displayed when there is either vertical overflow and the browser is scrolled downwards or when the browser's orientation has been changed from portrait to landscape and then back again (despite whether or not there is vertical overflow).Ĭhanging Orientation with Vertical Overflow // Without Overflow Normal URL and Menu Bars // Condensed URL Bar The issue only manifests itself in portrait mode if Safari is displaying its condensed URL bar, which replaces the normal URL and menu bars, and there is no vertical overflow. In order to reproduce the problem, the element must have a position of fixed or absolute, yet it doesn't matter whether you position the element with top and transform or bottom. The issue manifests itself when trying to align an element to the bottom axis of the viewport, and is a problem in both portrait and landscape mode. This issue dates back to at least iOS 12.2, but I imagine it's been a problem for much longer than that. I'm experiencing something strange in iOS 12.3.1 Safari.
0 Comments
Read More
Leave a Reply. |