Apple dragged their feet in adding support for PWAs in Safari, and when they finally did, limited the capabilities of a PWA so that native-like app functionality wouldn’t be possible, like notifications or a home screen icon shortcut – to name just a few of the many restrictions imposed by Apple.
But it goes beyond that. On iOS, the only web rendering engine allowed is Apple’s own WebKit, which runs Safari. Third-party iOS browsers such as Chrome can only use WebKit, not their own engines (as would be permitted in Windows, Android, or macOS). And it’s WebKit that governs PWA capabilities.
Safari is very good web browser, delivering fast performance and solid privacy features.
But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.
The enormous popularity of iOS makes it all the more annoying that Apple continues to hold back developers from being able to create great experiences over the web that work across all platforms.
Friday, July 30th, 2021
Wednesday, July 28th, 2021
If I could ask for anything, it’d be that Apple loosen the purse strings and let Webkit be that warehouse for web innovation that it was a decade ago.
Monday, October 19th, 2020
Continuous partial browser support
That’s not what happened though. Developers used vendor-prefixed properties as though they were stable. Tutorials were published that basically said “Go ahead and use these vendor-prefixed properties and ship it!” There were even tools that would add the prefixes for you so you didn’t have to type them out for yourself.
Browsers weren’t completely blameless either. Long after features were standardised, they would only be supported in their prefixed form. Apple was and is the worst for this. To this day, if you want to use the
clip-path property in your CSS, you’ll need to duplicate your declaration with
-webkit-clip-path if you want to support Safari. It’s been like that for seven years and counting.
Like capitalism, vendor prefixes were one of those ideas that sounded great in theory but ended up being unworkable in practice.
Still, developers need some way to get their hands on experiment features. But we don’t want browsers to ship experimental features without some kind of safety mechanism.
- Developers are able to register for an experimental feature to be enabled on their origin for a fixed period of time measured in months. In exchange, they provide us their email address and agree to give feedback once the experiment ends.
- Usage of these experiments is constrained to remain below Chrome’s deprecation threshold (< 0.5% of all Chrome page loads) by a system which automatically disables the experiment on all origins if this threshold is exceeded.
I think it works pretty well. If you’re really interested in kicking the tyres on an experimental feature, you can opt in to the origin trial. But it’s very clear that you wouldn’t want to ship it to production.
You could ship something that’s behind an origin trial, but you’d have to make sure you’re putting safeguards in place. At the very least, you’d need to do feature detection. You certainly couldn’t use an experimental feature for anything mission critical …but you could use it as an enhancement.
And that is a pretty great way to think about all web features, experimental or otherwise. Don’t assume the feature will be supported. Use feature detection (or
@supports in the case of CSS). Try to use the feature as an enhancement rather than a dependency.
If you treat all browser features as though they’re behind an origin trial, then suddenly the landscape of browser support becomes more navigable. Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”
You can also do it for well-established features like
geolocation. Instead of assuming that browser support is universal, it doesn’t hurt to take a more defensive approach. Assume nothing. Acknowledge and embrace unpredictability.
The debacle with vendor prefixes shows what happens if we treat experimental features as though they’re stable. So let’s flip that around. Let’s treat stable features as though they’re experimental. If you cultivate that mindset, your websites will be more robust and resilient.
Monday, September 28th, 2020
Friday, July 31st, 2020
This is a great talk by Hidde, looking at the history and evolution of cascading style sheets. Right up my alley!
Tuesday, July 14th, 2020
There’s a new project from Igalia called Open Prioritization:
An experiment in crowd-funding prioritization of new feature implementations for web browsers.
There is some precedent for this. There was a crowd-funding campaign for Yoav Weiss to implement responsive images in Blink a while back. The difference with the Open Prioritization initiative is that it’s also a kind of marketplace for which web standards will get the funding.
Examples include implementing the CSS
lab() colour function in Firefox or implementing the
:not() pseudo-class in Chrome. There are also some accessibility features like the
:focus-visible pseudo-class and the
inert HTML attribute.
I must admit, it makes me queasy to see accessibility features go head to head with other web standards. I don’t think a marketplace is the right arena for prioritising accessibility.
I get a similar feeling of discomfort when a presentation or article on accessibility spends a fair bit of time describing the money that can be made by ensuring your website is accessible. I mean, I get it: you’re literally leaving money on the table if you turn people away. But that’s not the reason to ensure your website is accessible. The reason to ensure that your website is accessible is that it’s the right thing to do.
I know that people are uncomfortable with moral arguments, but in this case, I believe it’s important that we keep sight of that.
I understand how it’s useful to have the stats and numbers to hand should you need to convince a sociopath in your organisation, but when numbers are used as the justification, you’re playing the numbers game from then on. You’ll probably have to field questions like “Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care”—even if the number is 1, the website should still be accessible because it’s the right thing to do.)
It reminds of when I was having a discussion with a god-bothering friend of mine about the existence or not of a deity. They made the mistake of trying to argue the case for God based on logic and reason. Those arguments didn’t hold up. But had they made their case based on the real reason for their belief—which is faith—then their position would have been unassailable. I literally couldn’t argue against faith. But instead, by engaging in the rules of logic and reason, they were applying the wrong justification to their stance.
Okay, that’s a bit abstract. How about this…
In a similar vein to talks or articles about accessibility, talks or articles about diversity often begin by pointing out the monetary gain to be had. It’s true. The data shows that companies that are more diverse are also more profitable. But again, that’s not the reason for having a diverse group of people in your company. The reason for having a diverse group of people in your company is that it’s the right thing to do. If you tie the justification for diversity to data, then what happens should the data change? If a new study showed that diverse companies were less profitable, is that a reason to abandon diversity? Absolutely not! If your justification isn’t tied to numbers, then it hardly matters what the numbers say (though it does admitedly feel good to have your stance backed up).
By the way, this is also why I don’t think it’s a good idea to “sell” design systems on the basis of efficiency and cost-savings if the real reason you’re building one is to foster better collaboration and creativity. The fundamental purpose of a design system needs to be shared, not swapped out based on who’s doing the talking.
Anyway, back to accessibility…
A marketplace, to me, feels like exactly the wrong kind of place for accessibility to defend its existence. By its nature, accessibility isn’t a mainstream issue. I mean, think about it: it’s good that accessibility issues affect a minority of people. The fewer, the better. But even if the number of people affected by accessibility were to trend downwards and dwindle, the importance of accessibility should remain unchanged. Accessibility is important regardless of the numbers.
Look, if I make a website for a client, I don’t offer accessibility as a line item with a price tag attached. I build in accessibility by default because it’s the right thing to do. The only way to ensure that accessibility doesn’t get negotiated away is to make sure it’s not up for negotiation.
So that’s why I feel uncomfortable seeing accessibility features in a popularity contest.
I think that markets are great. I think competition is great. But I don’t think it works for everything (like, could you imagine applying marketplace economics to healthcare or prisons? Nightmare!). I concur with Iain M. Banks:
The market is a good example of evolution in action; the try-everything-and-see-what- -works approach. This might provide a perfectly morally satisfactory resource-management system so long as there was absolutely no question of any sentient creature ever being treated purely as one of those resources.
If Igalia or Mozilla or Google or Apple implement an accessibility feature because they believe that accessibility is important and deserves prioritisation, that’s good. If they implement the same feature just because it received a lot of votes …that doesn’t strike me as a good thing.
I guess it doesn’t matter what the reason is as long as the end result is the same, right? But I suspect that what we’ll see is that the accessibility features up for bidding on Open Prioritization won’t be the winners.
Tuesday, October 29th, 2019
Tim ponders the hard work that goes into adding standards to browsers, giving us a system with remarkable longevity.
So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there?
His parting advice is perfect:
Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.
Wednesday, July 24th, 2019
Jon’s ranting about Agile here, but it could equally apply to design systems:
Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.
Monday, July 1st, 2019
If you ignore the slightly insulting and condescending clickbaity title, this is a handy run-down of eight browser features with good support:
- extra arguments in
- extra arguments in
defaultCheckedproperty for checkboxes,
wholeTextfor strings of text,
Thursday, August 30th, 2018
font-feature-settings value demonstrated in one single page.
Tuesday, August 7th, 2018
A great long-term perspective from Rachel on the pace of change in standards getting shipped in browsers:
The pace that things are shipping, and at which bugs are fixed is like nothing we have seen before. I know from sitting around a table with representatives from each browser vendor at the CSS Working Group how important interop is. No-one wants features to be implemented differently in browsers. This is what we were asking for with WaSP, and despite the new complexity of the platform, browsers rendering standard features in different ways is becoming increasingly rare. Bugs happen, sometimes in the browser and sometimes in the spec, but there is a commitment to avoid these and to create a stable platform we can all rely on. It is exciting to be part of it.
Friday, July 20th, 2018
Andy describes the technical approach he took building his handy reporting tool, My Browser:
Although the site is built with bleeding edge technology such as web components, it’s built with a progressive-first approach. This means that in order to get the best experience, you need to be on a modern browser, but to do the most basic function—reporting data, you can still do it by pressing a “generate report” button, which is the default state.
Not only is this a liberating way to work, it really pays off in performance:
We’re given so much for free to make a progressively enhanced website or web app. We’ve got feature detection and
@supportsin CSS which means that “My Browser” ships with no polyfills, fallbacks or hacks like Autoprefixer. The app degrades gracefully instead.
This has been a very refreshing way to work that I’ve enjoyed a lot. The fact that the whole thing comes in around 25kb tells you how effective progressive enhancement can be for performance too.
Tuesday, May 1st, 2018
What’s new in Microsoft Edge in the Windows 10 April 2018 Update - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog
Service workers, push notifications, and variable fonts are now shipping in Edge.
Wednesday, March 21st, 2018
A handy browser-based tool for examining font files to see which features they support.
Tuesday, October 31st, 2017
Thursday, August 24th, 2017
Jason lists the stages of gradually turning the Cloud Four site into a progressive web app:
And you can just keep incrementally adding and tweaking:
You don’t have to wait to bundle up a binary, submit it to an app store, and wait for approval before your customers benefit.
Monday, July 31st, 2017
Cameron counts the ways in which Flash was like a polyfill.
Yeah, that’s right: The Man In Blue is back!
Monday, January 30th, 2017
David picks up on one of the closing themes of Resilient Web Design—how we choose our tools. This has been on my mind a lot; it’s what I’ll be talking about at conferences this year.
That’s part of my job to ease processes and reduce frictions. That’s part of my job to take into account from the early beginning of a product its lasting qualities.
There’s a very good point here about when and how we decide to remove the things we’ve added to our projects:
We spend our time adding features without considering at the same pace the removal of useless ones. And still the true resilience (or is it perfection Antoine?) is when there is nothing more to take away. What are you removing on Monday to make our Web more resilient?
Monday, December 19th, 2016
A run-down of all the functionality that you get in browsers these days. One small quibble with the title: most of the features and APIs described here aren’t limited to mobile browsers. Still, this is a great reminder that you probably don’t need to create a native app to get the most out of a mobile device.
Tuesday, September 27th, 2016
Here’s a handy graph from Paul:
Powered by data from caniuse.com and StatCounter, this page indicates the percentage of users who have a browser that natively supports various web platform features.