Viewport height is taller than the visible part of the document in some mobile browsers

When trying to use a 100vh CSS value to build a new interface for a game that would use the full viewport, I discovered that this full height value meant the bottom of the game interface was partialy hidden behind the browser buttons bar or below the "fold" of some mobile browsers.

An issue with Apple iOS Safari

I first discovered this on my iPhone 5 and iPad 2.

Here is what this page looks like on an iPhone 5 :

The page rendering in portrait mode with visible browser chrome

The page rendering in landscape mode with visible browser chrome

100vh is computed for when the browser interface is hidden, after a scroll :

The page rendering in portrait mode with reduced browser chrome

The page rendering in landscape mode with reduced browser chrome

As suggested by Yoav Weiss there and there, I opened a bug in Apple Bug Reporter(#19879505) and Webkit Bugzilla.

Description

When trying to use a 100vh CSS value to build an interface for a game that would use the full viewport, I discovered that this full height value meant the bottom of the game interface was partialy hidden behind the browser buttons bar of Safari iOS on iPhone, or below the "fold" on iPad.

Steps to Reproduce

  1. Open http://lab.gasteroprod.com/vub/index-ios-issue.html on iOS Safari with an iPhone in portrait mode, or an iPad in portrait or landscape mode
  2. The bottom part of the "bottom right" box is not visible, the 100vh height container being taller than the visible part

Expected Results

I would have expected the viewport size (and the 100vh dimension) to be equal to the visible part of the page in the browser. It's called VIEWport after all.

I understand it means the viewport changes when the browser interface hides, but I find it better, and necessary for "full viewport" interfaces. Fullscreen API is not available either, so there is no simple way to fix this behavior.

Actual Results

The bottom part of the "bottom right" box is not visible, the 100vh height container being taller than the visible part

Configuration

iPhone 5 and iPad 2

Version & Build

iOS 8.1.3 (12B466), and other versions in the iOS simulator

Additional Notes

There is a JavaScript library that tries to fix some issues with viewport units in iOS, but it has issues too: https://github.com/rodneyrehm/viewport-units-buggyfill/issues/13

But not the only one…

In fact I saw later that iOS Safari is not the only one doing this.

Firefox on Firefox OS

I discovered later the same behavior on the browser of Firefox OS:

So what?

Are these behaviors browsers bugs, or the correct implementation of the standard, or is it open to interpretation?

February 23rd update

Webkit bug has been set to RESOLVED WONTFIX, with this explanation:

This is completely intentional. It took quite a bit of work on our part to achieve this effect. :)

The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS).

It is hard to show you the "looks like shit" part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting.

Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size.

From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.

March 4th update

The issue on Apple Bug Reporter has been closed with this comment:

This issue behaves as intended.

Meh…

The W3C CSS Working Group replied on Twitter with links to past discussions:

@nhoizey @7studio www.w3.org/TR/css3-values/#viewport-relative-lengths lists.w3.org/Archives/Public/www-style/2013Jan/0200.html lists.w3.org/Archives/Public/www-style/2013Jan/0312.html Donc, utiliser html { overflow: scroll; }

March 9th update

The W3C CSS Working Group suggestion doesn't fix anything, in iOS at least. Test it live here.

June 30th update

Boris, a friend, told be he saw a disturbing behavior of my text content when scrolling on this site:

@nhoizey j'ai un changement de taille de police au scroll… Bizarre!

— Boris 🚀 (@borisschapira) June 30, 2015

In fact, the viewport height changes when he scrolls and the browser chrome hides. Combine this with the fact that he font-size is partialy based on a vh value, and you understand that when scrolling and hiding the browser chrome, the text size was growing.

Here is a visual demonstration, from two screenshots he gave me:

The font-size increases when the user scrolls

Boris uses a OnePlus One running Android 5.0.2 and Chrome 43.0.2357.93.

So there is at least one browser that behaves as I want for my full height game screen… but it makes users wonder if there is an issue…

January 19th, 2016 update

People developing Chrome for Android now plan to change its behavior to match iOS Safari's one, claiming that “Safari’s been doing this for years without user/developer complaint”.

I've tried to answer[1], but I don't believe it will change anything. At least, we will have the same "bug" everywhere…

November 8th, 2016 update

Chrome will indeed now work like Safari.

There is a lot of interesting informations in this study about the differences between mobile browsers, and the proposed consensus.

December, 2016 update

David Bokan explains how Chrome will now behave starting with version 56: URL Bar Resizing.

Unfortunately:

The unintuitive choice of making vh units the largest possible viewport but the the smallest possible is to match Safari's behavior.

January 3rd, 2017 update

Jeremy Keith made the same observation, and concluded that "the result of this messiness is that the vh unit is practically useless for real-world situations with real-world devices".

February 22nd, 2017 update

Peter-Paul Koch makes the same observation that viewport size is a tricky topic, with many disparities among browsers, in his post Toolbars, keyboards, and the viewports.


  1. Thanks Yoav for the notification about this discussion! ↩︎

158 Webmentions

45 likes

1 repost

  1. Cédric Nirousset avatar

25 replies

  1. Smashing Magazine avatar Smashing Magazine
    @nhoizey Yes, noticed it, too. A lot of bugs to fix apparently.
  2. Nicolas Hoizey avatar Nicolas Hoizey
    @smashingmag indeed!
  3. Nicolas Hoizey avatar Nicolas Hoizey
    @smashingmag and a lack of consistency in browsers
  4. HTeuMeuLeu avatar HTeuMeuLeu
    @nhoizey Cette solution pour forcer l'affichage de l'UI de Safari semble résoudre le problème. Tu confirmes ? eventbrite.com/engineering/mo…
  5. Nicolas Hoizey avatar Nicolas Hoizey
    @HTeuMeuLeu je ne connaissais pas, il faudrait que je fasse des tests, mais le premier commentaire m’inquiète…
  6. Jason Grigsby, ☁4 avatar Jason Grigsby, ☁4
    Did you use WPT and then the tab? Or through the Cloudinary hosted page? The second page is slammed.
  7. Jason Grigsby, ☁4 avatar Jason Grigsby, ☁4
    see also https://t.co/k2aR4j4gPO
  8. Nicolas Hoizey avatar Nicolas Hoizey
    I was using the Cloudinary page, I will try with WPT, thanks!
  9. Jason Grigsby, ☁4 avatar Jason Grigsby, ☁4
    Just pick a location that doesn’t have a large queue on WPT. The problem appears to be getting through the WPT queue.
  10. Nicolas Hoizey avatar Nicolas Hoizey
  11. Patrick Meenan avatar Patrick Meenan
    Could also be that the UI doesn't handle edge or error cases. Like @grigs mentioned, accessing it from an existing WPT result may be best
  12. Nicolas Hoizey avatar Nicolas Hoizey
    I will let @cloudinary fix any issue, and try later… 😉
  13. Aaron Gustafson 🚀🕸 avatar Aaron Gustafson 🚀🕸
    The `content` provided by webmention.io is the full post (see webmention.io/api/mentions?t…). You could use a custom template & truncate.
  14. Nicolas Hoizey avatar Nicolas Hoizey
    Will do that, indeed. Maybe it would be safer to truncate even in the default template, of with a setting.
  15. Thomas Steiner avatar Thomas Steiner
    Hehe, your article definitely came up when I researched this in the past and also today. Nice work on keeping it updated!
  16. Nicolas Hoizey avatar Nicolas Hoizey
    Thanks! I think I should update it even more, and maybe add a tl;dr in the beginning…
  17. Dayton Lowell avatar Dayton Lowell
    What does Chrome do these days? I know your update it said it matches Safari, but does it still?



    If so, will they change to match again?
  18. Nicolas Hoizey avatar Nicolas Hoizey
    I think they all followed webkit’s lead. I have to check current state, through.



    Re-opening the bug doesn’t mean anything will change, but at least they are open to discussion!
  19. Thomas Steiner avatar Thomas Steiner
    Ugh, while this works on iOS Safari and in-app browsers like the one in Google Hangouts, it breaks in Chrome, since Chrome honors `-webkit-fill-available` (and consequently doesn't ignore it). Demo: 100vh.glitch.me.
  20. Matt Smith avatar Matt Smith
    Any idea why Chrome honors `-webkit-fill-available` and not ignore it? Bug? 🤔 But am I missing something, cuz my desktop Chrome handles your example fine.
  21. Thomas Steiner avatar Thomas Steiner
    Chrome 83 and Chrome 84 render it broken as in my screenshot. I’m not an expert, but it seems it’s not really in the spec anymore: drafts.csswg.org/css-sizing-3/#… (search for 'stretch', which is the actual name of 'fill-available' IIUC).
  22. Dave 🧱 avatar Dave 🧱
    Just to make things more confusing, for me (macOS Catalina, Chrome 81) the value works but doesn't respect resizing
  23. Thomas Steiner avatar Thomas Steiner
    Maybe @fantasai or @tabatkins as the spec editors can clarify what’s the correct behavior here.
  24. Thomas Steiner avatar Thomas Steiner
    Thanks for the reply; and sorry, it was hard to get the context. We were discussing whether the first screenshot with the footer _not_ at the bottom in Chrome from my tweet https://t.co/jwdvlk4GUz was the correct behavior for `min-height: -webkit-fill-available`.
  25. snemvalts
    Safari tends to be slow (or flat out non-responsive) to fix bugs. When their design of the Safari app cannot be implemented properly, web standards give way: https://nicolas-hoizey.com/articles/2015/02/18/viewport-heig...This has been a bug for 5 years or more.

87 mentions

  1. Itamar avatar Itamar
    If only all issues were this well documented. Thanks, @nhoizey nicolas-hoizey.com/2015/02/viewpo…
  2. Itamar avatar Itamar
    If only all issues were this well documented. Thanks, @nhoizey nicolas-hoizey.com/2015/02/viewpo…
  3. Page screenshot https://daveredfern.com/2016/use-units-css/
  4. Page screenshot http://wordpresstoolbag.com/aurelienpierre-on-plugin-photographers-gal...
  5. PinGoo avatar PinGoo
    J'hallucine avec ce bug 100vh iOS nicolas-hoizey.com/2015/02/viewpo…
  6. jacob jenkins avatar jacob jenkins
    sometimes I cry and program and sometimes I just cry nicolas-hoizey.com/2015/02/viewpo…
  7. 👑💖 funkelfiep avatar 👑💖 funkelfiep
  8. Nikita Prokopov avatar Nikita Prokopov
    Don’t try to build apps in a browser. Just stop. It’s impossible. Can’t even begin to imagine how impossible it is nicolas-hoizey.com/2015/02/viewpo…
  9. Alan Plum avatar Alan Plum
    TIL #css `height:100vh;width:100vw` is broken by design:nicolas-hoizey.com/2015/02/viewpo…
    Just use `position:absolute;top:0;right:0;bottom:0;left:0`.
  10. Ya avatar Ya
  11. Paul Martin avatar Paul Martin
    TIL, vh css units are basically unusable on mobile nicolas-hoizey.com/2015/02/viewpo…
  12. alsacreations avatar alsacreations
    Attention aux bugs des unités de viewport CSS sur mobiles (vh particulièrement) :nicolas-hoizey.com/2015/02/viewpo…
  13. Gil Barbara avatar Gil Barbara
    Viewport Height is dead. 💀 nicolas-hoizey.com/2015/02/viewpo…
  14. Stephen Nixon avatar Stephen Nixon
    My 100vh container was being overlapped by the controls in iOS Safari ... turns out, this is an intentional thing: nicolas-hoizey.com/2015/02/viewpo…
  15. Dimitry avatar Dimitry
    Грустная история, как 100vh перестали равняться 100% видимой области браузера по высоте — nicolas-hoizey.com/2015/02/viewpo…
  16. xcv58 avatar xcv58
    The best blog for VH units: Viewport height is taller than the visible part of the document in some mobile browsersnicolas-hoizey.com/2015/02/viewpo…
  17. Toma Nistor avatar Toma Nistor
    While trying to fix a #CSS height bug on my site, I found out that I'm part of a viewport war with #mobile browsers. nicolas-hoizey.com/2015/02/viewpo…
  18. Davide Lorigliola avatar Davide Lorigliola
    Mobile Viewport Total Madness nicolas-hoizey.com/2015/02/viewpo…
  19. Víctor Dieppa avatar Víctor Dieppa
    Why fix it, just break it on all browsers. nicolas-hoizey.com/2015/02/viewpo… via @nhoizey
  20. Víctor Dieppa avatar Víctor Dieppa
    Why fix it, just break it on all browsers. nicolas-hoizey.com/2015/02/viewpo… via @nhoizey
  21. Jack avatar Jack
    @gruber these issues have been around FOR YEARS. Just resolved it all by using iscroll eventbrite.com/engineering/mo… and nicolas-hoizey.com/2015/02/viewpo…
  22. Lennart avatar Lennart
    Viewport height is taller than the visible part of the document in some mobile browsers | @nhoizey | nicolas-hoizey.com/2015/02/viewpo…
  23. Christian Spanring avatar Christian Spanring
    The day your layout crumbles because you find out that viewport height is not what you think it is. nicolas-hoizey.com/2015/02/viewpo…
  24. Samuel Simões avatar Samuel Simões
    Viewport height is taller than the visible part of the document in some mobile browser ~ nicolas-hoizey.com/2015/02/viewpo…
  25. Jano avatar Jano
    Viewport height is taller than the visible part of the document in some mobile browsers nicolas-hoizey.com/2015/02/viewpo…
  26. ถุงใต้ตาซ้ายคุณรยู avatar ถุงใต้ตาซ้ายคุณรยู
  27. Elodie avatar Elodie
    @nhoizey Il semble que nous passions par les mêmes galères :D (nicolas-hoizey.com/2015/02/viewpo…)
  28. Jonas Jensen avatar Jonas Jensen
    Turns out the "vh" #css unit is unfit for mobile use, despite good global browser support: nicolas-hoizey.com/2015/02/viewpo… / adactio.com/journal/11690
  29. Page screenshot http://webandapp.fr/blog/2017/09/fullscreen-height-issue-reopened/
    There are quite a few layout components which use full-screen elements, not only overlays. Another use-case are intro- or landing pages with different sections, where each section has the minimum height of the browser window, often in combination with parallax scrolling effects. Making an element fill the visible screen height via CSS sounds simple, but there are more pitfalls than you might think, especially when you deal with mobile browsers.
    But before digging deeper, if there are pitfalls within…
  30. Matthew Johnston avatar Matthew Johnston
    Everytime you see that Safari address bar disappear when you scroll on your iPhone, someone working on CSS dies nicolas-hoizey.com/2015/02/viewpo…
  31. Christophe Camus avatar Christophe Camus
    Passer un moment à ne pas comprendre pourquoi mon height:100vh ne fonctionne pas sur mobile et tombé sur ça nicolas-hoizey.com/2015/02/viewpo… #wtf
  32. Mikael Ainalem avatar Mikael Ainalem
    The 100vh viewport issue on mobile shows the reality frontenders live in. Browser vendors need to give us a true full screen experience on mobile. Resizing browser toolbars/the viewport is not a good idea nor good UX. nicolas-hoizey.com/2015/02/viewpo…
  33. Page screenshot https://exceptionshub.com/ajax-upload-image-2.html
  34. Kai avatar Kai
    Viewport height is broken on mobile browsers and browser makers won't fix it: nicolas-hoizey.com/2015/02/viewpo…
  35. Gridonic avatar Gridonic
    The #CSS vh unit is quite messed up. @nhoizey’s very interesting article (nicolas-hoizey.com/2015/02/viewpo…) from 2015 sums it up pretty much.
  36. Popmotion avatar Popmotion
  37. Dian Xiao avatar Dian Xiao
    Turns out 100vh is not what you expect in mobile browsers (url bar shrinking) nicolas-hoizey.com/2015/02/viewpo…
  38. The Z Man avatar The Z Man
    After many hours banging my head against my desk, #TIL 100vh for real-world web sites is practically useless if you're using real-world devices -- nicolas-hoizey.com/2015/02/viewpo… #smh #dev #problems #mobile #unicorns
  39. Albert Song avatar Albert Song
    Thanks apple and google for destroying the vh unit.

    nicolas-hoizey.com/2015/02/viewpo…
  40. Ben Foster avatar Ben Foster
    The CSS vh unit sounds great in theory, but is (3 years later) still utterly useless in the real world nicolas-hoizey.com/2015/02/viewpo…
  41. Page screenshot https://codertw.com/ios/20462/
  42. Michael Burgstahler avatar Michael Burgstahler
    TIL that CSS viewport height unit, esp. 100vh, are messed up on iOS Safari and Android Chrome, due to dynamic URL bar resizing – which is not reflected in vh calculations.



    Avoid using this unit on mobile platforms.



    See: nicolas-hoizey.com/2015/02/viewpo…



    And: medium.com/samsung-intern…
  43. Page screenshot https://www.qqwenda.com/wenda/19382.html
  44. Stefan Vermaas avatar Stefan Vermaas
    omg... 100vh !== 100% of the *visible* viewport in webkit on mobile 😖#css



    nicolas-hoizey.com/2015/02/viewpo…
  45. [db:作者]
    这篇文章将介绍如何使用原生 JS (主要使用 ES6 语法)实现全屏滚动插件,兼容 IE 10+、手机触屏,Mac 触摸板优化,支持自定义页面动画,压缩后 gzip 文件只有 2k。完整源码在这 pure_full_page ,点这查看demo
    1)前面的话
    现在已经有很多全屏滚动插件了,比如著名的 fullPage ,那为什么还要自己造轮子呢?
    现有轮子有以下问题:
    首先,最大的问题是最流行的几个插件都依赖 jQuery,这意味着在使用 React 或者 Vue 的项目中使用他们是一件十分蛋疼的事:我只需要一个全屏滚动功能,却还需要把 jQuery 引入,有种杀鸡使用宰牛刀的感觉;

    其次,现有的很多全屏滚动插件功能往往都十分丰富,这在前几年是优势,但现在(2018-5)可以看作是劣势:前端开发已经发生了很大变化,其中很重要的一个变化是 ES6 原生支持模块化开发,模块化开发最大的特点是一个模块最好只专注做好一件事,然后再拼成一个完整的系统,从这个角度看,大而全的插件有悖模块化开发的原则。
    对比之下,通过原生语言造轮子有以下好处:
    使用原生语言编写的插件,自身不会受依赖的插件的使用场景而影响…
  46. IotaHosting.Org - Full Node Hosting for IOTA!











    %MINIFYHTMLb0659b6fa08cae774cb75ef6719594838%
  47. Page screenshot https://medium.freecodecamp.org/how-to-keep-your-footer-where-it-belon...
  48. Page screenshot https://epeak.info/2018/07/07/find-out-how-to-hold-your-footer-the-pla...
  49. Adefisayo avatar Adefisayo
  50. Seb 🌹🏴 avatar Seb 🌹🏴
    So I ran into this 100vh issue the other day. Webkit's response is pretty annoying, too: "This is completely intentional...": nicolas-hoizey.com/2015/02/viewpo…
  51. Kean Richmond avatar Kean Richmond
    Trying to use 100vh (viewport height) and of course things fuck up in iOS :(



    nicolas-hoizey.com/2015/02/viewpo…
  52. Samuel Vrablik avatar Samuel Vrablik
    This makes me sad. Always

    nicolas-hoizey.com/2015/02/viewpo…
  53. Sam Snelling avatar Sam Snelling
    What a bizarre bug / feature I've run into, and it's really well documented. vh / vw is unusable while scrolling in iOS



    nicolas-hoizey.com/2015/02/viewpo…
  54. Page screenshot https://blog.opendigerati.com/the-eccentric-ways-of-ios-safari-with-th...
  55. Page screenshot https://blog.opendigerati.com/the-eccentric-ways-of-ios-safari-with-th...
  56. manoi avatar manoi
    Das 100vh Problem im Safari
  57. Page screenshot https://ns-1441.meowwow.name/blog/archives/115
    おそらく初心者あるあるシリーズの一つ。モバイルとPC双方に対応したいわゆる「レスポンシブサイト」を作ったものの、モバイル端末での表示が崩れる。私も作品を展示するためのサイトを作る際に見事引っかかりました。
    作成したサイトをPCで表示した場合(ブラウザ:Google Chrome)
    同じサイトをiPad Proで表示した場合(iOSのChrome)。見切れたドロップダウンメニューに注目。どうしてこうなった( ^ω^ #)PCでは想定通りに表示されるのに、手持ちのiPad Pro(OSは最新版に更新しているためiOS12)での表示がおかしくなってしまったのです。Webページ全体(例えばbodyタグやページ全体の要素を包むdivタグ)の高さをCSSで「height: 100vh」で設定すると、なぜか画面の下側がはみ出してしまうのです。すぐに解決策を見たい方は→こちら※注:手元にあるモバイル端末がiOS12入りiPad Pro(10.5 inch)のみであることから、より古いOS、iPad Pro第2世代 (10.5 inch)以外の端末(特にandroid OS系端末)についてはどうなるのか確認…
  58. Page screenshot http://www.ix1.shop/archives/56987
  59. Piper Haywood
  60. Kathryn Ellingwood avatar Kathryn Ellingwood
    Prevent Address-Bar hiding in mobile Browsers

    I’m currently working on a website with a horizontal layout. All elements are position:absolute with javascript. Their size is calculated with window.innerHeight. My Problem is that despite the elements are no higher than the window’s height, I can scroll down (height of the addressbar). This is annoying in two ways. First it triggers the window-resize event which I neither want nor need at that time. And Second it does not play well with some content…
  61. Page screenshot http://www.3ydai.cn/archives/25684
  62. Mathias Abernathy avatar Mathias Abernathy
    Prevent Address-Bar hiding in mobile Browsers

    I'm currently working on a website with a horizontal layout. All elements are position:absolute with javascript. Their size is calculated with window.innerHeight. My Problem is that despite the elements are no higher than the window's height, I can scroll down (height of the addressbar). This is annoying in two ways. First it triggers the window-resize event which I neither want nor need at that time. And Second it does not play well with some content…
  63. チャリ走社長→山田元康→HTML5スタートアップ社長 avatar チャリ走社長→山田元康→HTML5スタートアップ社長
    モバイルブラウザーで全画面にしたくて100vh指定してもステータスバーの裏に表示されてしまうのはAppleが意図的にやってるんだな・・・

    HTML5アプリ対策だな・・・

    nicolas-hoizey.com/articles/2015/…
  64. Page screenshot https://inneka.com/programming/css/prevent-address-bar-hiding-in-mobil...
    Loading...



    Prevent Address-Bar hiding in mobile Browsers

    I'm currently working on a website with a horizontal layout. All elements are position:absolute with javascript. Their size is calculated with window.innerHeight. My Problem is that despite the elements are no higher than the window's height, I can scroll down (height of the addressbar). This is annoying in two ways. First it triggers the window-resize event which I neither want nor need at that time. And Second it does not play well with…
  65. Page screenshot https://inneka.com/programming/css/css3-100vh-not-constant-in-mobile-b...
    Loading...



    CSS3 100vh not constant in mobile browser

    I have a very odd issue... in every browser and mobile version I encountered this behavior:

    all the browsers have a top menu when you load the page (showing the address bar for example) which slide up when you start scrolling the page.
    100vh sometimes is calculated only on the visible part of a viewport, so when the browser bar slide up 100vh increases (in terms of pixels)
    all layout re-paint and re-adjust since the dimensions have changed
    a bad…
  66. Page screenshot https://inneka.com/programming/html/css3-100vh-not-constant-in-mobile-...
    Loading...



    CSS3 100vh not constant in mobile browser

    I have a very odd issue... in every browser and mobile version I encountered this behavior:

    all the browsers have a top menu when you load the page (showing the address bar for example) which slide up when you start scrolling the page.
    100vh sometimes is calculated only on the visible part of a viewport, so when the browser bar slide up 100vh increases (in terms of pixels)
    all layout re-paint and re-adjust since the dimensions have changed
    a bad…
  67. Page screenshot https://www.mybooam.tech/news/20017/2020/05/11/css-fix-for-100vh-in-mo...


    Send to HN



    CSS fix for 100vh in mobile WebKit
    Not long ago there was some buzz around how WebKit handles 100vh in CSS, essentially ignoring the bottom edge of the browser viewport. Some have suggested avoid using 100vh, others have come up with different alternatives to work around the problem. In fact, this issue goes further back a few years when Nicolas Hoizey filed a bug with WebKit on the subject (the short of it: WebKit says this is “intentional” 🧐).
    The other day I was doing some work with a…
  68. Page screenshot https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-mobile-web...
  69. SENDIL J




    CSS fix for 100vh in mobile WebKit
    Not long ago there was some buzz around how WebKit handles 100vh in CSS, essentially ignoring the bottom edge of the browser viewport. Some have suggested avoid using 100vh, others have come up with different alternatives to work around the problem. In fact, this issue goes further back a few years when Nicolas Hoizey filed a bug with WebKit on the subject (the short of it: WebKit says this is “intentional” 🧐).
    The other day I was doing some work with a basic flexbox…
  70. Page screenshot https://www.fvwebsite.design/fraser-valley-website-design/css-fix-for-...
  71. bear
    Exception or error:





    Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.







    Want to improve this question? Update the question so it's on-topic for Stack Overflow.

    Closed 2 years ago.



    Hey I’m a web developer and I’m looking for a way to emulate mobile devices which also displays their respective navigation bars, toolbars etc. In the ‘Device toolbar’ in Google Chrome (v58 on macOS) there’s a specific mode available for the Nexus 5X (and ‘supported devices…
  72. Page screenshot https://websitedesign-usa.com/css-fix-for-100vh-in-mobile-webkit/
  73. Page screenshot https://graphicdon.com/2020/05/15/css-fix-for-100vh-in-mobile-webkit/
  74. Page screenshot https://dinezh.com/css-fix-for-100vh-in-mobile-webkit/



    CSS fix for 100vh in mobile WebKit
    Not long ago there was some buzz around how WebKit handles 100vh in CSS, essentially ignoring the bottom edge of the browser viewport. Some have suggested avoid using 100vh, others have come up with different alternatives to work around the problem. In fact, this issue goes further back a few years when Nicolas Hoizey filed a bug with WebKit on the subject (the short of it: WebKit says this is “intentional” 🧐).
    The other day I was doing some work with a basic flexbox…
  75. Page screenshot https://1dmx.org/correction-css-pour-100vh-dans-webkit-mobile/
  76. Page screenshot https://www.seowebdesignllc.com/css-fix-for-100vh-in-mobile-webkit/
  77. Page screenshot https://pixallus.com/css-fix-for-100vh-in-mobile-webkit/
  78. Page screenshot https://www.new.pixel-forge.ca/2020/05/15/css-fix-for-100vh-in-mobile-...
  79. Page screenshot https://makemoneyupdaters.sample-sites.xyz/css-fix-for-100vh-in-mobile...
  80. Page screenshot https://cornerwire.com/css-repair-for-100vh-in-cellular-webkit/
  81. Page screenshot https://onumahkalusamuel.tk/css-fix-for-100vh-in-mobile-webkit/
    May 11, 2020
    Not long ago there was some buzz around how WebKit handles 100vh in CSS, essentially ignoring the bottom edge of the browser viewport. Some have suggested avoid using 100vh, others have come up with different alternatives to work around the problem. In fact, this issue goes further back a few years when Nicolas Hoizey filed a bug with WebKit on the subject (the short of it: WebKit says this is “intentional” 🧐).
    The other day I was doing some work with a basic flexbox layout – header,…
  82. Diel Duarte avatar Diel Duarte
    that kind of shit that makes me cry as a webdev.

    nicolas-hoizey.com/articles/2015/…
  83. Page screenshot https://flisks.com/html-css3-100vh-not-constant-in-mobile-browser
    Unfortunately this is intentional…
    This is a well know issue (at least in safari mobile), which is intentional, as it prevents other problems. Benjamin Poulain replied to a webkit bug:

    This is completely intentional. It took quite a bit of work on our part to achieve this effect. 🙂
    The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that…
  84. にっし avatar にっし
    レスポンシブ対応つらい
    nicolas-hoizey.com/articles/2015/…
  85. Page screenshot https://medium.com/@susiekim9/how-to-compensate-for-the-ios-viewport-u...
  86. Page screenshot https://www.hsablonniere.com/once-upon-a-blog--9849zg/
  87. Stavros Bastakis avatar Stavros Bastakis
    Have you fallen on the interesting 100vh layout issue for mobile web applications? 🤯 😃

    Check more on that: nicolas-hoizey.com/articles/2015/…

    #webdevelopment #javascript #uiux