This is a great talk by Hidde, looking at the history and evolution of cascading style sheets. Right up my alley!
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.
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.
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,
font-feature-settings value demonstrated in one single page.
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.
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.
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.
A handy browser-based tool for examining font files to see which features they support.
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.
Cameron counts the ways in which Flash was like a polyfill.
Yeah, that’s right: The Man In Blue is back!
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?
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.
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.
Paul argues that the biggest problems for interoperability on the web don’t come from support (or lack of support) for entire features, but from the frustrating inconsistencies when features land in different browsers at different times with different implementations:
- Platform inconsistencies hurt us more than big feature differences, we should start to try and prioritize aligning the platform
- We need better tools to help us understand what the inconsistencies are and guidance on how to manage them
- Developers should raise more issues to keep browser vendors accountable when there are differences
Remy looks at the closing gap between native and web. Things are looking pretty damn good for the web, with certain caveats:
The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn’t be fun, right?).
That’s why there’ll always be some other technology that’s ahead of the web in terms of features, but those features give the web something to aim for:
Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!
Whereas before we needed polyfills like PhoneGap (whose very reason for existing is to make itself obsolete), now with progressive web apps, we’re proving the philosophy behind PhoneGap:
If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.
The proxy browser Opera Mini is one of the most popular mobile browsers in the world, and rightly so. Ire Aderinokun has put together a handy collection—based on caniuse.com data—of all the features that are unavailable or only partially available in that browser. The point here is not to avoid using these features, but to make sure you’ve got a solid fallback in place:
This isn’t about bashing the problem, but figuring out the solution.
It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.
The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.
Do not panic:
On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.