Grrr…
Chrome, Edge and Firefox updates usually reach 95% of users within three months. But Safari updates are tied to a new release of the underlying operating system, so they take around 19 months to reach the same usage, and some updates may even need a new device.
This is so shameful. And glad as I am to see new features landing in Safari, as long as they hobble updates like this it’s all just pissing in the wind.
Nice to see Clearleft’s browser support policy get a shoutout from Rachel during her Google IO talk.
- Basic functionality should work on any device that can access the web.
- Extras and flourishes are treated as progressive enhancements for modern devices.
- The UI can look different and even clunky on older devices and browsers, as long as it doesn’t break rule #1.
A fascinating look at the modern equivalent of the Longitude problem.
Trys describes exactly the situation where you really do need to use the Shadow DOM in a web component—as opposed to just sticking to HTML web components—, and that’s when the component is going to be distributed and you have no idea where:
This component needed to be incredibly portable, looking great on any third-party website, in any position, at any viewport, with any amount of content. It had to be a “hyper-responsive” component.
A solid detailed in-depth report.
The sheer amount of resources needed to support the current and forecast demand from AI is colossal and unprecedented.
It’s very exciting to see the support for popovers—I’ve got a use-case I’m looking forward to playing around with.
Although there’s currently a bug in Safari on iOS (which means there’s a bug in every browser on iOS because …well, you know).
It’s a dream team of former Clearlefties: Harry and Cennydd joined forces to investigate and write an in-depth report looking into deceptive design practices used by Microsoft to stop people changing their default browser from Edge. They don’t pull their punches:
We judge that Microsoft cannot justify the use of these techniques, and should stop using them immediately. If they do not, we would welcome – where the law provides for it – regulatory intervention to protect against these harms.
These updated definitions makes sense to me:
- Newly available. The feature is marked as interoperable from the day the last core browser implements it. It marks the moment when developers can start getting excited and learning about a feature.
- Widely available. The feature is marked as having wider support thirty months or 2.5 years later. It marks the moment when it’s safe to start using a feature without explicit cross-browser compatibility knowledge.
Some lovely scroll-driven animations illustrate this great little microsite.
There’s something very pleasy about the chunky design that harkens back to the Zeldmanesque early web.
- Be skeptical of PR hype
- Question the training data
- Evaluate the model
- Consider downstream harms
This is a terrrific presentation by Chris, going through some practical implementations of modern CSS: logical properties, viewport units, grid, subgrid, container queries, cascade layers, new colour spaces, and view transitions.
Seven principles for journalism in the age of AI
- Be rigorous with your definitions.
- Predict less, explain more.
- Don’t hype things up.
- Focus on the people building AI systems — and the people affected by its release.
- Offer strategic takes on products.
- Emphasize the tradeoffs involved.
- Remember that nothing is inevitable.
After nearly two decades of fighting for this vision of the internet, the people who believed in federation feel like they’re finally going to win. The change they imagine still requires a lot of user education — and a lot of work to make this stuff work for users. But the fundamental shift, from platforms to protocols, appears to have momentum in a way it never has before.
Our smarter, richer betters (in Babel times, the king’s name was Nimrod) often preach the idea of a town square, a marketplace of ideas, a centralized hub of discourse and entertainment—and we listen. But when I go back and read Genesis, I hear God saying: “My children, I designed your brains to scale to 150 stable relationships. Anything beyond that is overclocking. You should all try Mastodon.”
So many gems in this piece by Paul Ford:
The Fediverse apps are all built on a set of rules called the ActivityPub standard, which is a little like HTML had sex with a calendar invite. It’s a content polycule. The questions it evokes are the same as with any polycule: What are the rules? How big can this get? Who will create the chore chart?
Mastodon is not a platform. Mastodon is just a tiny part of a concept many have been dreaming about and working on for years. Social media started on the wrong foot. The idea for the read/write web has always been different. Our digital identities weren’t supposed to end up in something like Twitter or Facebook or Instagram.
Decentralisation, Federation, The Indie Web: There were many groups silently working on solving the broken architecture of our digital social networks and communication channels – long, long before the “web 3” dudes tried to reframe it as their genius new idea.
I’ve been a part of this for many years until I gave up hope. How would you compete against the VC money, the technical and economical benefits of centralised platforms? It was a fight between David and Gloiath. But now Mastodon could be the stone.
Mastodon has gotten two things right that no other social media giant has even seriously attempted:
- If you follow someone on Mastodon, you’ll see everything they post; and
- If you leave a Mastodon server, you can take both your followers and the people you follow with you.
The most common criticism of Mastodon is that you must rely on individual moderators who may be underresourced, incompetent on malicious. This is indeed a serious problem, but it isn’t the same serious problem that Twitter has. When Twitter is incompetent, malicious, or underresourced, your departure comes at a dear price.
On Mastodon, your choice is: tolerate bad moderation, or click two links and move somewhere else.
On Twitter, your choice is: tolerate moderation, or lose contact with all the people you care about and all the people who care about you.
A terrific piece by Maggie Appleton that starts with a comparison of graphical user interfaces and command line tools—which reminds me of the trade-offs between seamless and seamful design—and then moves into a proposed paradigm for declarative design tools:
Small, scoped areas within a graphical interface that allow users to read and write simple programmes
The headline is clickbaity, but the advice is solid. Use progressive enhancement and don’t worry about polyfilling.
When I say ‘Stop supporting IE’ it means to me that I won’t go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.
JavaScript doesn’t get executed on very old browsers when native syntax for new language features is encountered. However, thanks to GitHub being built following the principle of progressive enhancement, users of older browsers still get to interact with basic features of GitHub, while users with more capable browsers get a faster experience.
That’s the way to do it!
Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.
Read on for the nitty-gritty details…