Safari — The New Internet Explorer for Web Developers: The Battle with Mobile Safari’s
date
Jul 23, 2023
slug
safari-the-new-internet-explorer-for-web-developers-the-battle-with-mobile-safaris
status
Published
tags
webdevelopment
browsers
javascript
html
css
summary
type
Post
Disclamer: This post serves as a cathartic rant, offering insights into the challenges faced by web developers, without providing a definitive solution.
The White Space Issue
Introduction:
As web developers, we are no strangers to browser quirks and compatibility issues. For many of us, the dreaded days of wrestling with Internet Explorer’s lack of support for web standards are still etched in our memories. However, as technology evolves, new challenges arise, and for some developers, Safari on iOS devices is becoming the modern-day equivalent of Internet Explorer.
The Issue:
Recently, I encountered a perplexing problem while working on a web application — white space appearing in Mobile Safari when the keyboard was opened.
Initially, when I set out to solve the white space issue in Mobile Safari, I was excited and confident that I would find a quick and elegant solution. As an experienced web developer, I never imagined that this seemingly simple problem would transform into an exasperating journey, leading me to write what I feared would become a failure blog.
The White Space Mystery:
It all began innocently enough — a white space appearing in Mobile Safari when the keyboard opened. Initially, I dismissed it as a minor problem with a straightforward solution. Little did I know that this simple issue would haunt me for days and nights to come.
Safari — The Usual Suspect:
Without a second thought, I pointed fingers at Safari. Past encounters with this browser had often left me troubled, even when I wasn’t focused on cross-browser compatibility. My suspicions seemed confirmed when the issue appeared non-existent on Mobile Chrome.
Trying Different Approaches:
To resolve the issue, I tried various strategies. I attempted to prevent Safari from enhancing the user experience by adding
user-scalable=no, but this didn't solve the problem. Adding overflow: hidden to every element seemed like a quick fix, but it proved ineffective.Debugging Nightmare:
When I attached my phone to Safari’s developer tools, I noticed something odd — the white space was not a margin or padding, but it was outside the HTML. Even with
overflow: hidden applied to every possible element (html, body, and more), there was still an unwanted scroll.
The Hunt for Clues:
In my desperation, I discussed the issue with fellow developers. One theory was that Safari might be trying to push the input field when it appears at the bottom of the page. However, changing the input’s position didn’t resolve the problem.
Flex and Sticky Positioning:
I considered the impact of using flex and sticky positioning in the layout. To my surprise, removing all sticky and fixed positioning did not help. As a last resort, I changed the layout to use scrollable divs instead of relying on window scrolling, but the issue persisted.
The Window.innerHeight Horror:
In my desperation, I focused on viewport-related issues, hoping that dynamic height calculations using
--vh variable would save the day. But to my horror, I discovered that window.innerHeight was unreliable. The value changed with every scroll triggering window resize, rendering it completely unpredictable - an unacceptable trait for such a fundamental API.
I even attempted using
scrollIntoView as a possible workaround. I thought that manually scrolling to the bottom of the HTML whenever the user encountered whitespace in the viewport might help. However, to my dismay, scrollIntoView didn't work in this state, and there was no means to calculate the y coordinate accurately to manually scroll, given the unreliable behavior of window.innerHeight. This effort left me feeling more helpless as I realized that even some unconventional solutions couldn't rescue me from the quagmire.Fear of the Unknown:
As a developer, I rely heavily on APIs like
window.innerHeight for responsive design, parallax effects, and other interactive experiences. The thought of such a critical tool becoming unpredictable was nothing short of terrifying. How can we build sophisticated web applications if we cannot trust the fundamental building blocks?No Help from Safari Team:
Desperate for answers, I scoured forums and developer communities, only to find fellow developers pleading with the Apple and Safari teams to address this and other related issues. The lack of a clear solution was disheartening.
Although in an attempt trying to find help in the comments, at some point I just started to enjoy it (people have very creative ways to express frustration)
Some thread running around same issue:
A Bug I Couldn’t Solve:
After exhausting all my efforts, I reluctantly had to admit defeat. I will now attempt to address this issue at a design level, accepting it as a bug failure for me — a developer who prides themselves on solving problems.
Living with Temporary Workarounds:
For now, I have resorted to disabling some
touchmove events to suppress unintentional scrolls. It's far from an ideal solution, but it's the best I can do until a proper resolution is found.Conclusion:
As a developer, the fear of Safari becoming the new Internet Explorer is all too real. The white space issue in Mobile Safari serves as a stark reminder of how even seemingly minor problems can spiral into monumental challenges. Until a concrete fix is provided, we must rely on our adaptability and ingenuity to work around these obstacles and deliver the best possible user experience. Let’s hope that in the near future, Apple’s Safari team acknowledges and addresses these issues, sparing developers from further frustration and helplessness.
Viewport related finding:
Just to mention, have already tried
-webkit-fill-available; lvh, dvh, svh But these don’t reflect with open and closed keyboard. Also the whole viewport related bargains are not connected to the whitespace issue overall as per my finding.Longer discussions and technical updates related to viewport issue:
Nicolas Hoizey has researched this quite a bit: https://nicolas-hoizey.com/articles/2015/02/18/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers/