
Safari is the new IE - abusedmedia
http://fabiofranchino.com/blog/css-height-parent-flex-safari-issue/
======
korm
Safari is not as bad as IE was compared to other browsers. However, calling it
the 'new IE' is accurate if the definition is 'the browser with the worst
support of new features and most bugs'. Here is a comparison
[http://html5test.com/compare/browser/safari-10.2/ios-10.3/ed...](http://html5test.com/compare/browser/safari-10.2/ios-10.3/edge-15/firefox-53/chrome-58.html)

What is especially frustrating for web devs is that all browsers on iOS are
Safari underneath. We have to deal with those weird bugs and missing features
the same painful way we dealt with IE, hence the title of the article. Saying
that it's not as bad is not the point, IE 11 was also not as bad as IE6, we
still had to deal with its quirks.

~~~
ddebernardy
Safari doesn't compare with how IE was in its heydays.

In IE times, it was the majority browser and web shops were complaining that
they were developing on less popular platforms (typically Firefox, and
Netscape before it) and then ranting about how IE did things differently. Had
they developed for IE all along with an aim for compatibility with FF, they'd
have done things differently and, in many cases, compatibility wasn't that
hard if you targeted lower common denominator - that is, a few earlier
versions of each browser.

Sure, you'd miss out on the latest browser features, but that's not what web
dev was about then. Rather, it was - depending on the shop - about making a
site work on all platforms, or about making it work on IE and to hell with
other platforms - with great despise from the rest of the community.

For some reason, things changed in recent years. Chrome is now dominant, and
for whatever reason developing against its latest version has become the new
normal, with web shops complaining that other browsers aren't keeping up fast
enough, and no echo chamber to counter that discourse by pointing out that
"hey, why aren't you targeting older browsers to begin with?" In case it needs
reminding, iOS 7 is from 2013 and iOS 5 is still running on 2010 devices.
That's only a few years ago. For comparison, we coped with IE6 for well over a
decade, and XP (from 2001) only recently got deprecated.

~~~
Drdrdrq
True.

But in some ways current situation with Safari is worse. With IE you could at
least say "download a proper browser if you want proper experience" (if you
had the luxury of not being in servitude to your visitors). With Safari it's
more like "get a proper phone", which is far from costless.

On the bright side, Apple is also hurting themselves with this approach.
Missing a good browser will only speed up the decline of iOS.

------
neilalexander
Drastic title for an incredibly weak article that barely even bothers to make
a case. So Safari has a bug. Why does that warrant immediately labelling it
abandonware?

~~~
frozenport
"Safari is the new IE" has been a complaint for many years. The author is
providing supporting evidence.

Here is an article from 2015 [http://www.businessinsider.com/apple-safari-web-
browser-is-b...](http://www.businessinsider.com/apple-safari-web-browser-is-
becoming-the-new-internet-explorer-2015-7)

~~~
zghst
If anything, these journalist are incredibly misinformed and shallowly
invested in the issue (they do love clicks though). There's not a sentence
about the power usage of browsers, performance on mobile browsers, the mass
amount of APIs that have been added over the past few years, the evolution of
JavaScript that is happening in tandem with new features that are being
released, not even a sentence about how these APIs are extremely immature and
still a WIP; all things that if taken in perspective will highlight the
nuances of Safari's strategy of slow adoption.

Apple could make a browser that has all these features (where APIs are slow to
being adopted on sites that users most use, low impact) or they could keep
investing in iOS (where APIs are mass adopted from day one on apps used by
hundreds of millions, high impact).

~~~
bradleyjg
Why is it an either/or? They are the largest company by market cap in the
world with more than $8B in profit last quarter. They should be able to handle
both.

~~~
zghst
It is precisely an either/or because it has made $8B in profit last quarter.
Apple as a massive company must make thousands, hundreds of thousands of tiny
decisions to make it's business more profitable.

Investing in iOS attracts more customers and buy in to its products and
services. Investing in Safari is not a key differentiator for their business
and rivals will be able to easily implement the same features. Apple is smart
not to play Google's game.

If Apple were to engage in this, the browser now becomes a selling point of
the phone. Apple goes from iOS/iPhone company to Safari company. They give
away their offering/unique selling point that no other company has, along with
their massive advantages as a market leader.

Because their tech and business strategy is more developed in this space
(browsers), Google can start acquiring customers at a lower cost than Apple
without having to differentiate its core product more than the fact that it
has more APIs/features. We see Google already does this to a degree, they
market their products more on the feature set rather than the mission and
brand.

Web technologies also inherently support Google's business strategy, the more
APIs in the browser, the more data Google can collect on Apple's users, the
more advanced targeting they can do to swipe away Apple's customers and
collect intelligence on what Apple is up to. Do not be fooled, every time
there is an API added to the browser, there are teams of people at Google
ready to capitalize on it to help drive profits.

It would be a bad, bad bet for Apple to start all of sudden focusing its
energies on Safari. As a SWE, it is completely understandable why Apple gives
Safari little love, I'm okay with it.

------
HugoDaniel
meh, desktop Safari is actually a very good browser. It is the fastest of all
browsers in macos for a bunch of operations and their support for ES6 features
beats all the other browsers (99% in [https://kangax.github.io/compat-
table/es6/](https://kangax.github.io/compat-table/es6/) ).

Also one could argue that if Apple did not invest so much in WebKit then
chrome would have had a harder time achieving its current usage and would
probably be a very different browser than what it is today.

My 2cents

~~~
ko27
> their support for ES6 features beats all the other browsers

That's really grasping for straws. All modern browsers almost fully support
ES6 features. Tail optimization are more controversial because they can
actually lead to a performance decrease in some cases.

Far more important are things like custom elements and service workers on
which Safari is lagging behind.

~~~
geocar
> Tail optimization are more controversial because they can actually lead to a
> performance decrease in some cases.

How exactly can the tail-call elimination optimization decrease performance?

Sounds more like an implementation problem.

~~~
lvh
Both TCO and PTC can decrease performance easily for a bunch of reasons. TC39
addressed this[0] when considering explicit tail call sites. Reasons vary from
Windows ABI (Chakra) to something as simple as "now I have to figure out if
this is really a PTC" \-- and if your function has a PTC but that only gets
invoked once, it's not hard to see how the extra analysis pressure doesn't
weigh up to the elided stack frame. JS engines were already extremely
optimized, it's not like you're taking a CS student's first lisp interpreter
and adding TCO. (Fortunately, some of the litmus tests for whether you can
apply PTC are encapsulated within strict mode, and the compiler stages
definitely know that for free already.)

[0]: [https://github.com/tc39/proposal-ptc-
syntax#performance](https://github.com/tc39/proposal-ptc-syntax#performance)

~~~
geocar
I remain unconvinced that just because it's difficult for a couple of
JavaScript implementations, that we're still not talking about an
implementation problem.

How exactly does anyone think that v8 doing something badly, is proof that
something cannot be done well?

~~~
lvh
I don't know which "anyone" you're referring to, but the argument I made about
analysis pressure isn't implementation-specific, and neither are the concrete
issues raised in both the TC39 notes I linked and elsewhere (they affect
Chakra primarily, and *Monkey/V8 secondarily). The parts of a JS
implementation (or really, any JIT) that decides to inline portions of code,
attempt to detect loops and unroll them,... are already central to those
implementations. I hope it's not difficult to see why a change that directly
impacts that might have negative consequences elsewhere. Indeed, _because_
this is implicit and part of the spec, implementations can't take the simple
multi-staged path they did before: they _have to_ do the PTC dance. I've heard
no argument why the PTC mode should be intrinsically faster than the non-PTC
mode (yes; you elide a stack frame at the cost of a whole-function analysis
pass -- heuristically, "stack frame" isn't the expensive one of the two). This
is why STC was proposed: it allows an impl to decide at _one_ location how to
handle a function, in an obvious-to-the-parser way. No other code paths are
affected. To contrast with PTC: even a compiler that knows with
epistemological certainty that a particular call will happen only once or even
never, _still has to do the PTC dance_.

However, you're asking me to prove a negative. I've given arguments, which
apparently you find unconvincing. The people you are disagreeing with (not I)
are responsible about 85% of the JavaScript engines on the Internet, an
incredibly competitive space with billions in funding. I submit that they are
probably neither incompetent nor lazy. (Evidence for "not lazy": the V8 team
implemented it and turned it off.) If you are convinced that it's a
(presumably fixable) implementation problem, I'm sure they'd love a patch or
at least something more actionable than your insistence that they're doing it
wrong.

~~~
geocar
> I hope it's not difficult to see why a change that directly impacts that
> might have negative consequences elsewhere.

Sure, but at the risk of repeating myself: That sounds like an implementation
problem.

> I've heard no argument why the PTC mode should be intrinsically faster than
> the non-PTC mode

There's a simple one: Hitting the stack less means you hit less memory.

> The people you are disagreeing with (not I) are responsible about 85% of the
> JavaScript engines on the Internet, an incredibly competitive space with
> billions in funding. ... I'm sure they'd love a patch

Happy to oblige. I'll implement TCO on V8 for a billion dollars in a way that
beats these benchmarks.

> However, you're asking me to prove a negative.

And you're making straw men instead: At the beginning of your response, it's
not even clear you read my complaint, but at the end, it's quite clear.

The simple answer would probably have been "yes, it's about an implementation,
but it remains unknown where else we can go", but instead you doubled down...

~~~
lvh
I'll repeat myself: it is not an implementation problem that a compliant
implementation needs to do necessarily more work. You say:

> there's a simple one: Hitting the stack less means you hit less memory.

But I explicitly acknowledge this in my comment:

> (yes; you elide a stack frame at the cost of a whole-function analysis pass
> -- heuristically, "stack frame" isn't the expensive one of the two)

(Completely ignoring that there are already plenty of optimizations where a
compliant interpreter may avoid the stack frame already anyway, so it's not
even true that PTC must be faster for that reason.)

You keep picking on V8, but remember that there is so far only 1 major JS
implementation that managed to do this without impact. It would seem that it's
more probable that it's the other way around: it's an implementation detail
that JSC had it easy.

> And you're making straw men instead: At the beginning of your response, it's
> not even clear you read my complaint, but at the end, it's quite clear.

I'd be happy to address this point, but I genuinely don't know which straw man
I've supposedly built.

~~~
geocar
> > > I've heard no argument why the PTC mode should be intrinsically faster
> than the non-PTC mode

> > there's a simple one: Hitting the stack less means you hit less memory.

> But I explicitly acknowledge this in my comment!

Not really sure what your point is. If you agree that's an argument as to why
tail-call elimination should be intrinsically faster, I'm not sure why you'd
say it isn't.

I can't shake this feeling you think you're having a very different argument
than I am.

> remember that there is so far only 1 major JS implementation that managed to
> do this without impact.

Which for some reason you think means this isn't an implementation issue.

~~~
lvh
> But I explicitly acknowledge this in my comment!

I did not put an exclamation mark there, but a colon, pointing out the
specific reason why PTC can end up slower.

------
ddebernardy
Anecdotal, but this doesn't match my own experience. When developing for the
web I usually develop on Safari. More specifically for a first-gen iPad
running Safari Mobile. And then, for whatever reasons, it almost always works
on other browsers pretty much as is - the main exceptions being very old
devices running ancient versions of IE.

(Admittedly I aim to make sites that degrade well and work _without_ JS, so
that might be an important caveat in an age of Angular and what have you.
Perhaps I'm stuck in y2k and still think a site should render in 0.2s on all
but 10+ year old browsers. [Shrugs])

~~~
n42
That is because Safari's feature support is the lowest common denominator of
the other browsers. By developing on it you are ensuring you don't use
features every other browser but Safari supports.

~~~
ddebernardy
> By developing on it you are ensuring you don't use features every other
> browser but

Sure. But isn't developing against the least common denominator _precisely_
what web development has been all about in the past 20 years or so?

Edit: Just to expand on that...

Then, there was a laundry list of web shops that were targeting IE first
because "more advanced" and complaining about other browsers because they
"suck". And it looked wrong to just about everyone else who targeted other
browsers because Microsoft.

Now, we've a laundry list of web shops that are targeting Chrome first because
"more advanced" and complaining about other browsers because they "suck". And
for some reason those browsers should all catch-up and fast because Google?

~~~
pmontra
If Safari would run on Windows and Linux maybe everybody would develop with it
and take advantage of this least common denominator thing (but still wish it
would get on par with the other browsers.) Unfortunately it is not.

This app store first / web second policy served well Apple bottom line. Too
bad web developers are paying for it with extra work and this is the point of
the post.

------
zghst
A few bugs don't really make Safari the new IE. There will always be bugs and
differences with rendering engines, that is the price of competition. However
IE was a completely different class of shit sandwich that inflicted horror
onto all devs who had to work with it.

~~~
racl101
Agreed.

Saying Safari is the new IE is like saying Trump is the new Hitler.

Not even close.

Just no.

------
lexicality
I suspect all the people disagreeing with this either

A) Are not web developers

B) Use macs as their primary development platform

C) Have never had a user using iOS 7 complain that your website is entirely
broken and not be able to replicate or debug it because every mac in your
office is using OSX 10.10 and Apple have jigged it so you can't run an
emulator for iOS <9 and everything on the computer (Except iTunes) refuses to
believe the iOS 7 device exists when you finally persuade the customer to
bring it in to you.

~~~
lexicality
(OTOH at least it has a vague attempt at developer tools - with Samsung
Internet you're on your own matey)

------
dieulot
Here’s an irritating bug that popped on Safari 10.1 (iOS 10.3) that strains
the use of CSS variables: You can’t just use a variable to declare a box-
shadow’s color opacity, you need an intermediate variable.

Demo: [https://codepen.io/anon/pen/YxmQdj](https://codepen.io/anon/pen/YxmQdj)

Apple versus Google keeping devices up-to-date is a reversed problem on the
web: iOS’s web browser updates only with new OS releases, and they don’t come
to all devices. iPhones 5 (and iPads 4) will be stuck with that bug forever.
On Android you can use Chrome’s latest version if you’re on ≥ 4.1 and
Firefox’s if you’re on 4.0. 99% of Android users are.

Even if you’re very aggressive on focusing only on recent browsers for your
website, you need to handle Safari bugs for _years_.

Safari is far from being as bad as IE ≤ 8, but it sure is the most annoying
browser when you’re targeting only recent ones.

------
digi_owl
I am as weary with Chrome, but for a different reason.

While Safari lags, Chrome seems to introduce more and more Chrome-isms onto
the web.

~~~
zghst
Web fragmentation, unfortunately is built in to our community, but my hope is
that we won't ever see an era of fragmentation like the HTML5 era. I'm okay
with Chrome-isms, as long as they're not too radical.

~~~
pdimitar
I think both you and me would agree that Google aims to make them radical.

Just today I changed my Chrome's search engine to DuckDuckGo. Of course, I get
periodically politely asked if I am sure that this is my correct search engine
setting. _< facepalms>_ As an Eastern European, I'd shut them down the same
instant on this basis alone, no questions asked. Shame that we don't run the
world. :D

An off-topic for sure but the gist is: Google wants to entangle you in their
web. They are just much more subtle compared to Microsoft and thus almost
nobody notices. So, less Chrome-isms, please.

------
0x0
This is only going to get worse as newer iOS versions drop support for older
hardware, especially iPads. It is doubly concerning since Apple bans browsers
from the app store unless they just use the iOS-provided webkit engine for, so
these devices are stuck with legacy Mobile Safari versions for the end of
time.

As more and more modern iDevices become legacy while still being perhaps
"powerful enough", I think we will start to see a persistent population of web
users similar to the clan of IE6 users that took forever to shake off.

~~~
linopolus
Oh right, of course few years old android phones can still be updated
officially (-> by the average user, too), being way better this way.

------
lukeman
The first example seems to work fine in iOS 11, but congrats on the clickbait
title.

~~~
zghst
To be fair, iOS 11 is only a couple of weeks from being adopted from hundreds
millions of people. Our community isn't as proactive in testing against
unreleased software as the native iOS community. :disappointed_face:

------
dschu
Why not simply just div { height: 100vh } though? No overflow rules on the
body needed

------
jasonkostempski
Luckily, it doesn't have near the numbers IE 6 ever had and it's not something
a company would require their employees to use for work applications long
after EOL, that was the real pain of IE.

------
neoyagami
It works the other way arround too. 2 years ago part of a site in production
stoped working just because how chrome loaded some js libs at loading time.
Ff,safary heck even ie worked ok but chrome.

------
jmisavage
I fixed his bug by changing the height on panel from 100% to 100vh. No need
for extra markup like his fix plus as someone else mention iOS 11 doesn't have
this problem and that most likely means the next desktop version will that fix
also.

~~~
korm
This is not a fix, on mobile 100vh and 100% are different due to the auto-
hiding address bar.

------
z3t4
IE still holds the crown here. Lots of "enterprise" still use IE (not Edge),
and IE have not got that much updates lately. That said I've had more issues
with Safari then IE.

------
ftxrcc
This article barely makes a point for itself. Why is this on HN?

------
mozumder
Wasn't this "bug" originally meant to reproduce IE behavior for compatibility
purposes with IE?

------
drcongo
Safari won't be the new IE until it has an IT department enforceable
compatibility mode which breaks everything forever.

------
submeta
I don't know about the challenges for a web dev. But as a MacOS user I love
Safari. It is very fast, it does not drain my battery and it gives me an
increadibly streamlimed experience (bookmarks sync across all my Apple
devices, I can continue a session that I started on my iOS device on my Mac).

Chrome kills my battery. Firefox is way to slow (startup time).

------
oblib
Durn whippersnappers, when I started developing for the web Apple didn't even
have a web browser. Personally, I dev on a Mac and use and test with Safari,
Firefox, and Chrome and to be fair they're all great.

I can deal with little CSS issues but what Safari really needs is Service
Worker support.

------
firefoxd
The great things about CSS is that there are many ways to achieve the same
result.

You just found one incompatible way of doing it.

------
junkculture
Safari may be broken but it's not as broken as ie6 was back in the day.

------
kylec
Safari isn't the new IE for one big reason: it's the only rendering engine on
iOS, which means if you want to support mobile web, you _have_ to support it,
and that won't change anytime soon.

~~~
ezequiel-garzon
Can't you download other browsers in iOS? In any event, it may not be relevant
if most iOS users don't bother.

~~~
Viper007Bond
They're all Safari underneath.

~~~
ezequiel-garzon
Thanks for replying! (I don't own an iOS device, so please bear this in mind
before further dowloading, dear fellow HNers.) If all browsers render the same
way, what is the point of downloading Chrome or Firefox, just syncing? Thanks
again.

~~~
Viper007Bond
Pretty much. Different UI and features but all the same rendering engine.

