QuirksBlog - Safari
Part of Browsers.
During the introduction of the iPhone X a hilarious gif made the Twitter rounds, showing a list scrolling past the new notch.
I asked the question any web developer would ask: “Hey, is this even possible with web technology?” Turns out it is.
(We should probably ask: “Hey, is this a useful effect, even if it’s possible?” But that’s a boring question, the answer being Probably Not.)
So for laughs I wrote a proof of concept (you need to load that into the iPhone X simulator). Turns out that this little exercise is quite useful for wrapping your head around the visual viewport and zooming. Also, the script turned out to be quite simple.
With the iPhone X’s notch came
safe-area-inset, as explained here. It turns out that
safe-area-inset is 0 on iOS11 devices that are not the iPhone X. This may sound logical, but I wonder if it is. Also, the value remains static, even when you zoom in.
Oh my God, oh my God. Apple thinks it has a bright idea, but craps all over your beautiful responsive sites. Even worse, it’s being inconsistent from iPhone to iPad. I don’t know what they were smoking when they thought this up, but I want some.
OK, so what’s going on? This morning a follower pointed out an article that describes how Safari iOS makes a total fucking mess of the meta viewport when the site is hosted on a .mobi domain.
When I reviewed the reactions to my There is no WebKit on Mobile post, it became pretty clear that few had expected its conclusion that there is no single WebKit on Mobile. Overall, it seemed that most people were pretty surprised, and hurried to revise their ideas of the mobile browser market. That was the point of the article, so I was happy.
(I’m still tinkering with the interface, by the way, and I didn’t have the time to finish my current revision. So the coloured bars are temporarily gone, but they’ll return in the future.)
Last week I spent a lot of time on WebKit in order to produce a comprehensive comparison of all WebKits. My purpose was to prove there is no “WebKit on Mobile,” and to gain some more insight in the complicated relations between the various WebKits.
Therefore I now present the Great WebKit Comparison Table. In it I compare 19 different WebKits on 27 tests.
There’s some browser news to discuss, and I thought I’d bundle it all in one entry. Maybe I’ll even do this more often; it seems a good feature for this blog. But I’m not promising anything!
This weekend I started testing some new browsers, and meanwhile I’ve updated the HTML and CSS tables. There were no surprises. I’m continuing with the Events tables, but they’re so large and sometimes so complicated that I’m not sure when I’ll finish.
In this installment we’ll take a look at IE8RC1 and some reactions to it, Safari 3.2, Chrome’s lack of a “Check for updates automatically” feature and Opera’s antitrust complaint.
Currently I'm working on a big revision of the Events Compatibility Tables. And no the new table is not yet online because I'm not ready yet.
Testing event support is really awesomely complicated. I've been working steadily for two weeks now, and I still find new bugs and oddities daily, and twice on Sundays.
In any case, I discovered something remarkable when I studied the mousemove event. It sheds light on the way browser vendors keep track of each other's implementations nowadays, and on things that can go wrong.
Update: The bug described in this entry is an OS problem, and not a browser bug.
Well, I've been using Safari Windows for a few weeks now, and I though it's time for a report. This report is only about the Windows version, because I can't install the Mac one. Why not? Because I don't have the right OS X version.
Yesterday I downloaded Safari 3.0 Windows as soon as I found out it was available. It looks fine. Below you find a list of CSS changes, as well as a curious bug that appears on a minority of Windows systems.
Apple just released Safari 1.3.1 without fuss. I found one important improvement over 1.3: the
unload event, which was badly broken in 1.3, is now restored to its ancient reliability.
Update: Safari used to download images with
display: none only when they, or their parent element, were toggled to
display: block. Unfortunately version 1.3.1 (and maybe 1.3) reverted to downloading the images anyway. Test page.
Two days ago Apple's team launched Safari 1.3, being part of the OS X.3.9 upgrade (once again named after a fierce predator, but I forget which one). Despite numerous bug fixes, the new release is marred by extremely serious