Good news and bad news…
The good news is that web notifications are coming to iOS—my number one wish!
The bad news is that it won’t happen until next year sometime.
Okay, so I didn’t get many of the answers, but nonetheless these are excellent questions!
(Ah, how I long for the day when we can once more engage in quizzo and picklebacks at National Mechanics.)
- Is this really a problem?
- Does the problem need to be solved?
- Does the problem need to be solved now?
- Does the problem need to be solved by me?
- Is there a simpler problem I can solve instead?
This site is not meant to be exhaustive, but rather a useful guide—our FAQ for design understanding. We hope it will inspire discussion, some questioning, a little soul searching, and ideally, a bit of intellectual support for your everyday endeavors.
The Design Questions Library goes nicely with the Library of Ambiguity.
The title is somewhat misleading—currently it’s about native lazy-loading for Chrome, which is not (yet) the web.
I’ve just been adding
loading="lazy" to most of the iframes and many of the images on adactio.com, and it’s working a treat …in Chrome.
Less than 24 hours after I put the call out for a solution to this gnarly service worker challenge, Trys has come up with a solution.
At Codebar the other night, I was doing an intro chat with some beginners. At one point I touched on DNS. This explanation is great for detailing what’s going on under the hood.
What makes a startup ecosystem thrive?
What do people plan to do once they’re over 35?
Is an income of $160K enough to survive?
What kind of car does Mark Zuckerberg drive?
My first reaction to this was nervousness. Of all the companies to trust with intercepting and rerouting page requests, Google aren’t exactly squeeky clean, what with that whole surveillance business model of theirs.
Still, this ultimately seems to be a move to improve the end user experience, and I’m glad to see this clarification:
Lite pages are only triggered for extremely slow sites, so we encourage developers to measure how well their pages are currently performing over slow networks.
Lite pages as a badge of shame (much like AMP in my eyes).
This is a really clever technique from Scott that he unveiled at An Event Apart in Seattle. It uses a header sent by a service worker to distinguish between returning and new visitors—much neater than relying on a cookie. I’ve updated my service worker on The Session to use this technique now.
Harry breaks down
cache-control headers into steps that even I can understand. I’ll be using this a reference for sure.
“What if someone doesn’t browse the web like I do?”
What an excellent question! And what an excellent bit of sleuthing to get to the bottom of it. This is like linguistic spelunking on the World Wide Web.
Oh, and of course I love the little sidenote at the end.
I remember Jason telling me about this weird service worker caching behaviour a little while back. This piece is a great bit of sleuthing in tracking down the root causes of this strange issue, followed up with a sensible solution.
There are some handy performance tips from Ben in this slide deck.
In this talk we’ll study how browsers determine which requests should be made, in what order, and what prevents the browser from rendering content quickly.
Jake’s blow-by-blow account of uncovering a serious browser vulnerability is fascinating. But if you don’t care for the technical details, skip ahead to to how different browser makers handled the issue—it’s very enlightening. (And if you do care for the technical details, make sure you click on the link to the PDF version of this post.)
A thorough explanation of the history and inner workings of Cross-Origin Resource Sharing.
Like tales of a mythical sea beast, every developer has a story to tell about the day CORS seized upon one of their web requests, dragging it down into the inexorable depths, never to be seen again.
I had fun answering these questions.