I’m a big fan of Safari in general. My loathing of Safari on iOS is largely restricted to the menu bar. For clarity, I’m talking about the UI at the bottom with the forward/backward icons in:


That bar isn’t hostile in principle; rather it’s the actions that invoke/dismiss its presence and its hijacking of the bottom 44px of the viewport that make it a constant frustration and problem for web pages.

iOS Safari wack-a-link

Users can’t fully enjoy ‘app like’ layout patterns on iOS. The kind of layouts popularised by iOS itself:


Fancy a game of wack-a-mole? Try making a fixed menu bar that sits within the bottom 44px of your web page/app. Scroll down the page just a little so the menu bar recedes and then try and tap the links/buttons in your fixed menu bar. How d’ya like them Apples (pun intended)? Every time Safari registers a touch in this area it pops up the Safari menu bar and you have to click what you clicked again. Every. Single. Time.

It’s a bit weird to me that these kind of layout patterns, that Apple champions natively, aren’t a problem with Windows Mobile & Android on the mobile web, just Safari on iOS.

It doesn’t need to be an ‘app like’ fixed bar. Safari on iOS considers the bottom 44px of the viewport sacrosanct in general. Plain old links that are unfortunate enough to be scrolled into that area have to be tapped twice too. That area of Safari is like some sort of ‘touch deity’; strictly off limits to all but those who understand what’s going on under the hood.

There’s no way around this frustration. Back in iOS7 we had the minimal-ui meta tag. If you remember, this gave us visual/practical equivalence with ‘Add to Home Screen’ (providing of course you have the requisite <meta name="apple-mobile-web-app-capable" content="yes"> in there).

That is to say, on iOS7 with minimal-ui present, the page loaded with a minimal amount of browser chrome by default. Users got the menu bar back by clicking the header chrome. Apple subsequently removed minimal-ui as a thing. I can appreciate that move; having no obvious back button on some pages and not others could be bad for users.

However, there are more problems with the current iOS Safari menu bar beside usability. From a technical perspective, here are a few:

  • the flexible viewport height means that window.innerHeight provides different results depending upon whether the page has just loaded or how far you have scrolled. Makes sense because the inner height is changing but, err, dunno — weird
  • there is no API/meta tag supported by Safari iOS that allows the page to be loaded with the menu bar hidden by default
  • There is no way to dismiss the bar from the UI other than by scrolling
  • There is no way to let clicks in that bottom 44px area actually click on first touch
  • The computed length of 100vh doesn’t get updated when the viewport size changes. That’s plain weird

I made a litle test page to demonstrate some of this. Load it up in Safari and scroll to see the difference, and the difference again when you save to home screen and then run it from there.

In addition, take a look at another demo my colleague, Tom Millard, made. This allows you to disable touch move on the body (as per the previous post) but then move your finger in that bottom 44px area again and you’ll see that it all falls apart.

Wish list for Safari on iOS

  • Stop hijacking that bottom 44px area. Let the menu bar appear when a user scrolls up or taps the top chrome
  • Make 100vh always actually equal to 100vh, the result being it would be a dynamic value as the Safari chrome expands/contracts (the only way around this currently is to make something absolute with top, bottom, left right set to zero but you still get a horrid redraw as the chrome shifts in and out). There are perhaps some side-effects of this I’ve not considered that make this undesirable so I’m all ears on that? But if innerHeight is being updated I think it makes sense that vh works too
  • bonus points — how about allowing us to size something across the whole viewport without always scrolling the content below it (more about that in the last post)?


Am I wrong about this? Has Safari actually got it right?

If it’s a problem for you/your organisation too I need your help. I’ve opened a dialogue about this with Apple employees but they need any metrics, further uses cases, evidence of support tickets you have received off that back of this etc. before they will consider changing the current behaviour.

I implore you, if you have any strong feeling, data, anecdotal evidence on this pattern being a problem, please comment below.

Learn to use CSS effectively, 'Enduring CSS' is out now

Get $5 off HERE ↠

Write and maintain large scale modular CSS and embrace modern tooling including PostCSS, Stylelint and Gulp