That unusual behaviour I wrote about with the Web Share API in Safari on iOS is now officially a bug—thanks, Tess!
Ah, what a wonderful treasure trove this is! PDF scans of Apollo era press kits from a range of American companies.
- Official NASA
- Lunar Module
There’s something so fascinating about the mundane details of Isolation/Quarantine Foods for Apollo 11 Astronauts from Stouffer’s.
Now this is a feature request I can get behind!
I’m serious about this. It’s is an excellent proposal for WebKit, similar to the never-slow mode proposed by Alex for Chromium.
Here’s an interesting insight on how WebKit is going to handle the cleanup of unused service workers and caches:
Service worker and Cache API stored information will grow as a user is browsing content. To keep only the stored information that is useful to the user, WebKit will remove unused service worker registrations after a period of a few weeks. Caches that do not get opened after a few weeks will also be removed.
Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.
That’s an impressive turnaround.
Well, that escalated quickly! Service workers are now available in Safari’s Technology Preview, which means it won’t be long before it lands in Safari proper.
Everything offline’s coming up Milhouse!
This could be a one-word article: don’t.
More specifically, don’t design websites for any specific device. That way lies pain (and it is not the way of the web).
But read on for a textbook example of how not to introduce new CSS properties. Apple proposed the new syntax that they’re shipping. Now it’s getting standardised …with a different name. So basically Apple are shipping the equivalent of a vendor-prefixed property without the vendor prefix.
I’ve never been so excited by a single diff in a JSON file.
Service workers are coming to Safari.
A starter kit of CSS that gives you some basic styles that you can tweak with custom properties.
For when you don’t need the whole boot.
I approve this message!
A really great overview of using
prefers-reduced-motion to tone down CSS animations.
This post was written by James Craig, and I’m going to take this opportunity to say a big “thank you!” to James for all the amazing accessibility work he has been doing at Apple through the years. The guy’s a goddamn hero!
An Enigma machine of one’s own.
Finally! Apple are being sued for refusing to allow any non-Webkit browsers to be installed on iOS.
I’m not usually in favour of legal action but in this case, there doesn’t seem to be any other recourse.
We would be delighted at Nexedi to create a Web browser for iOS with better HTML5 support based on a recent version of Blink library for example. But as soon as we would publish it, it would be banned from Apple’s AppStore. Many developers have experienced this situation already. Many companies are being hurt by this situation. Some companies have already begged Apple to improve HTML5 support in iOS with little significant results.
Ted has snuck a blog post out from behind Apple’s wall of silence, and it’s good news: WebKit is not going to use vendor prefixes for new features.
This looks like it could be a very nifty tool to have at your disposal while coding. I like that it’s editor-agnostic.
Everything you never knew you wanted to know about the Millennium Falcon, wrapped up in one unsurprisingly insanely detailed essay from Michael.
This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:
touch-action: manipulation;on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.
It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.
Everyone who calls for WebKit in Internet Explorer is exactly the same kind of developer who would have coded to Internet Explorer 15 years ago (and probably happily displayed the best viewed in badge).
It’s happening again, and every petulant, lazy developer who calls for a WebKit-only world is responsible.