Internet Explorer still exists. Just. And while its last-supported version, Internet Explorer 11, generally behaves nicely, it’s the little things that can make a website fall on its face. Then we go back to those IE 6 days – remember how 24-bit transparent PNGs didn’t even work without JavaScript intervention? Internet Explorer liked to make up its own rules and stand apart from the crowd. There were specifications it could follow, but nope, Internet Explorer knew better. Apparently.
Safari isn’t like that. Let me get that clear – Safari is modern, and does a lot well.
But that’s the point.
It does some things too well. Like following the rules. Well, OK, I like rules and specs, so there’s no such thing as being “too good” at following rules - either you follow them or you don't. This is computer science after all... hello, boolean, it's this or that. Anyway, Safari follows the rules, where as other browsers might follow 99.9% of the rule. But is that 100% coverage being a nuisance in the meantime? So others, technically, aren't following them. Yeah, nit picking, I know.
High level view – there are the W3C specifications that are followed for how web languages should process code – a set of blueprints if you will – and browser engine developers follow these to ensure their product follows the spec – so the Chrome, Safari, Firefox devs.
Day to day, I don’t use Safari. I use Brave for my personal web browsing, Firefox for my dev work (I like their dev tools the best) and Chrome for the things that Brave has a hissy fit with (FreshDesk is the only one so far that I just can’t get my login to work in Brave). But I do use Apple devices, and fall over the Safari quirks there.
Most recently, aka today, a client who has been testing a dev build of their latest system reported an issue with the layout of a notifications panel. Odd, I thought, looked fine to me last time I checked. As it turns out, a recent update patched that – but I did notice that on iPadOS and iOS, the notifications panel, which use Vuebar for internal scrolling, was not actually allowing the scroll. But yet Firefox worked, and yet Chrome didn’t.
OK, so clearly a Webkit issue. Righto, let’s get it fixed. Safari’s caching was pissing me off so switched to Chrome, did some element inspection, and the fix was relatively simple, and took just a few minutes – just needed one more style declaration.
Awesome. Except it still doesn’t work in Safari.
Is Safari caching still? Nope, reloaded with a force-refresh, and I can see the code when inspecting it all. How odd.
Basically, the notifications panel was dynamic in height up until a certain height – max height. But the child container, the element that scrolls within the fixed height container, was still at its 100% height, which was greater than that fixed height. But only in Safari.
Googling around (with a weird collection of generic keywords such as “webkit overflow hidden height not explicitly set”) finally led to a simple fix – put position absolute on the problem child.
Awesome. But then it disappears altogether. Hello fun keywords “safari overflow max-height without absolute” to find an awesome description of the problem, and the why behind it. This does make total logical sense.
But doesn’t solve my issue.
So knowing why Safari is behaving the way it is made me approach it from a different perspective… and rely on a little bit of JavaScript too. I still have my fixed height up to a maximum size, but given the notifications panel is triggered by a JavaScript action, as Vue renders that list, it also explicitly sets its height to be the currently rendered height of the parent. Which for this case works – as window resize or click outside will close the panel for UX. But if I were to keep the panel open, I’d also need to listen for different browser updates. But hey, that’s not the point here.
Basically it nearly 2 hours of time to get a previously working function to work again. And just for Safari.
This is not the first time Safari has been the problem child of modern browsers. Every now and then a simple flex instruction decides to behave erratically, or situations like this today. I do feel like a bit of special care is needed to keep Safari happy. And this is such a priority given how iOS and iPadOS render their sites using the same engine (and same blueprint too) – so it’s bigger than just those using desktop Safari (hi, all 5% of you).
But this then got me thinking – in some ways, Safari is the new Internet Explorer – it needs a bit of extra TLC to work as the developer expects (given code already runs in Edge, Firefox and Chrome without issue).
However, it is not really Safari at fault: the other browser engines are not actually following the specs correctly themselves.
The Stack Overflow comment above does make logical sense. And is very clear at explaining this behaviour in Safari.
Reading the W3C’s CSS spec, Safari is actually behaving correctly and as it should, and it is Firefox and Chrome that are being lenient (and ignoring that 0.01% of the rule). But it is that minute detail that actually has a big impact.
At the end of the day, a good developer (hi there, I like to think I’m one) will be able to correctly develop their site – including layout, styles and interactions – and deliver a consistent experience across devices and browsers. And I’ve been able to do that. It was just a bit odd this morning to have one modern browser behaving differently to the others… and technically be correct too.
That’s a big difference from Internet Explorer. Maybe the old IE devs printed the W3C specs, and sat on them for a booster seat instead of actually following it. At least Safari is following the rules. Even if Firefox and Chrome are making assumptions for us in this specific edge case.
