Blog #9: Safari – The new 'Internet Explorer' of the modern era?

If you ask a Frontend Engineer about their biggest fear after fixing a bug on Chrome, the answer will often be: "Will it run on Safari?".

I was once in charge of a landing page for a major product launch event. The design was extremely gorgeous with glassmorphism effects, backdrop-filter, and moving gradient strips. On my machine (Chrome), the website looked like a work of art. But just 1 hour before the link was sent to the client, my boss—a loyal iPhone user—called me screaming: "Why is the website blank, and where did the menus go?".

I opened Safari on my Mac, and true enough... my "work of art" now looked like a ruin from the 2000s.

Welcome to the pain known as "Cross-browser compatibility."

1. Safari and the "Lone Trail" attitude

While Safari is a great browser for privacy and battery efficiency, for web developers, it often lags behind in supporting the latest CSS/JS standards. Or worse, it supports them but in a... very unique way.

Common culprits:

• Regex Lookbehind: Runs fine in Chrome, but Safari reports a syntax error that crashes the whole app.
• Date Parsing: new Date('2024-04-05') might work, but new Date('2024-04-05 10:00') will return Invalid Date on Safari.
• CSS Flexbox/Grid: Pixel-perfect display errors that you'll never understand why.
• VH Unit: The nightmare with the address bar automatically hiding and showing on iOS.

2. The Problem: When Layout "disappears" because of 1 CSS line

In that landing page project, I used a very modern feature called gap for Flexbox.

/* Code that ruins the UI on older Safari versions */
.container {
  display: flex;
  gap: 20px;
}

At the time, older versions of Safari on iOS did not understand gap for Flexbox (only for Grid). As a result, all elements stuck together without spacing. Not to mention, I used backdrop-filter for background blurring and forgot that Safari needs the -webkit- prefix. Consequently, the frosted glass effect turned into a muddy patch, covering all the text underneath.

3. The Debug Process: Remote debugging and wrong assumptions

Debugging on Safari is an ordeal if you don't have an Apple device. Even with a Mac, connecting an iPhone to inspect the console is quite cumbersome.

Initially, I thought it was a JS crash. I busied myself checking Polyfills for Array.flat() or Object.fromEntries(). But the Console was clean. As it turned out, the error was in the CSS.

The lifesaver for me then was BrowserStack. It allowed me to test the website on dozens of different iOS versions. Seeing the layout break on the virtual screen of an iPhone 12, I started looking up each CSS property on Can I Use.

The final fix:

• Reverted to using margin instead of gap (or used a fallback with @supports).
• Added full -webkit- prefixes for filter effects.
• Used the min-height: -webkit-fill-available unit to replace 100vh on mobile.

4. Counter-argument: Should we abandon old Safari?

Many will say: "Just update to the new version, who uses the old one!". But in reality, iPhone users often don't update iOS immediately, and Safari comes with the OS. If your clients are wealthy (the group that uses iPhones a lot), you can't tell them: "Your device is too old, I don't support it."

Professional Frontend means ensuring a Graceful Degradation experience—beautifully polished on modern browsers, but still usable and not broken on older ones.

5. Junior vs. Senior: Multi-platform Vision

A Junior developer often only develops and tests on their favorite browser (usually Chrome). They believe the world only has the Blink engine.

A Senior developer always has at least 3 browsers open: Chrome, Firefox, and Safari. They consider Can I Use their bedtime reading. Before using a "cool" new CSS property, they always check its support percentage. They never trust the fancy appearance on their local machine until it has been tested across "virtual machines."

Sustainable solutions:

• Integrate Autoprefixer into the build process to automatically add vendor prefixes.
• Use PostCSS to transform modern CSS into more compatible formats.
• Set up Visual Regression Testing to detect layout changes on different browsers before deploying.

6. Lessons Learned

Safari isn't an enemy; it's a strict "judge" that helps you write standard code.

• Never trust 100vh on mobile.
• Always check Date formats before parsing.
• Avoid advanced Regex if there's no Polyfill.
• Borrow or buy an old iOS device for testing. Simulators sometimes don't reflect reality 100%.

Final advice: As long as Safari exists, our Frontend profession will remain "valuable." Because making the web run on every browser is a supreme skill.

---

Source code may be the same, but how a browser 'interprets' it is another story.