Below you find the last seven QuirksBlog entries.
Today I spent about an hour in writing a few very simple Intersection Observer tests, two hours in running them in a few browsers, and now an hour in writing down the results.
I’ve only just started my research, but can already draw a few odd conclusions, which make me fear Intersection Observers are not yet ready to be deployed on a large scale, particularly on mobile.
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.
A few weeks back the most exciting viewport news of the past few years broke: Chrome 61 supports a new visual viewport API. Although this new API is an excellent idea, and even includes a zoom event in disguise, the Chrome team decided that its existence warrants breaking old and trusty properties.
I disagree with that course of action, particularly because a better course is readily available: create a new layout viewport API similar to the visual one. Details below.
For years, whenever I thought about the gig economy, I noted to myself that gigs are great for students, who like to be flexible with their time and don't need a lot of money, but not so great for others.
This is not a particularly original thought, so I didn’t pursue it any futher. That’s why it took me until last Sunday to realise that gig jobs being the same as student jobs is not at all a coincidence.
From September on I am looking for new clients. In fact, I am looking so hard that I updated my About page, something I haven’t done for years.
I’d love to get a job around setting up or troubleshooting an in-house front-end team, or representing unknown browsers to unsuspecting front-enders. I always like fundamental browser research jobs as well, but they’re relatively hard to get since there is limited global interest in that service. Or I can give a new “how to deal with browsers” workshop I’m developing — or even make a website under certain circumstances which boil down to “no frameworks or libraries.”
I have no clue if this is going to help, and I would really hate to be forced into a full-time job, since I’ve become too used to freelancing. But we’ll see.
Anyway, spreading the word would be greatly appreciated.
Although there’s a lot of heated discussion around diversity, I feel many of us ignore the elephant in the web development diversity room. We tend to forget about users of older or non-standard devices and browsers, instead focusing on people with modern browsers, which nowadays means the latest versions of Chrome and Safari.
This is nothing new — see “works only in IE” ten years ago, or “works only in Chrome” right now — but as long as we’re addressing other diversity issues in web development we should address this one as well.
Even older entries
See the July 2017 archive and beyond.