VH, VW units and Crazy IOS Mobile Browser Rendering

Peege151 picture Peege151 · Aug 11, 2014 · Viewed 10.2k times · Source

I thought it would be a good idea to use relative units to start a new project of mine. As I was working on it I was checking the chrome emulation to make sure everything worked well on those devices as well, and it looked good.

Then I pushed it to heroku and it looked good on my macbook, but when I actually loaded it on my iPad, I wanted to throw it out the window...

#bannerTop {
    position:relative;
    text-align: center;
    width:100vw;
    height:70vh;
    min-height: 70vh !important;
    max-height:70vh !important;
    background-image: asset-url('skycloudsalpha.jpg');
    background-repeat: no-repeat;
    background-position: 50% 75%;
    z-index:-1;
}

I am using VH units. I suspect this may be the problem?

There may be some other underlying problem, but I'm not sure how to debug my issue because everything looks fine on the emulator, but not on the device itself. I've spent about three hours on this now and would greatly appreciate some help.

Thank You!

Answer

jcesarmobile picture jcesarmobile · Aug 11, 2014

As you can read on caniuse.com

Partial support in iOS7 is due to buggy behavior of the "vh" unit.

known issues:

  1. Chrome does not support viewport units for border widths, column gaps, transform values, box shadows or in calc() until version 34.
  2. iOS Safari (both 6 and 7) does not support viewport units for border widths, column gaps, transform values, box shadows or in calc().
  3. iOS 7 Safari sets viewport unit values to 0 if the page has been left and is returned to after 60 seconds.
  4. Internet Explorer 9 in print-mode interprets vh as pages. 30vh = 30 pages
  5. iOS 7 Safari recalculates widths set in vh as vw, and heights set in vw as vh, when orientation changes.

More info about the buggy behavior

http://blog.rodneyrehm.de/archives/34-iOS7-Mobile-Safari-And-Viewport-Units.html

And a polyfill https://github.com/rodneyrehm/viewport-units-buggyfill