All twelve are out, and all twelve are excellent deep dives into exciting web technologies landing in browsers now.
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.
This is a thoughtful proposal for a browser feature from Bram. Very convincing!
Twitter is a chatroom, and the problem that Twitter really solved was the discoverability problem. The internet is a big place, and it is shockingly hard to otherwise find people whose thoughts you want to read more of, whether those thoughts are tweets, articles, or research papers. The thing is, I’m not really sure that Twitter ever realized that this is the problem they solved, that this is where their core value lies. Twitter kept experimenting with algorithms and site layouts and Moments and other features to try to foist more discoverability onto the users without realizing that their users were discovering with the platform quite adeptly already. Twitter kept trying to amplify the signal without understanding that what users needed was better tools to cut down the noise.
Twitter, like many technology companies, fell into the classical trap by thinking that they, the technologists, were the innovators. Technologists today are almost never innovators, but rather plumbers who build pipelines to move ideas in the form of data back and forth with varying efficacy. Users are innovators, and its users that made Twitter unique.
Robin adds a long-zoom perspective on my recent post:
This is a great succinct definition of progressive enhancement:
Progressive enhancement is a web development strategy by which we ensure that the essential content and functionality of a website is accessible to as many users as possible, while providing an improved experience using newer features for users whose devices are capable of supporting them.
Smart advice on future-proofing and backward-compatibility:
There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.
Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.
If you haven’t seen it yet, the new redesign of WebPageTest is lovely!
Eric has a written a clear and measured explanation that I hope Alex and Jake will read, given their petty snarky reactions to Webkit shipping a feature (reactions that do more harm than good to their cause—refuting their bullshit has taken time and energy away from the legitimate criticisms of Apple’s rendering engine monopoly on iOS; this whole debacle has been one big distraction from far more important browser bugs).
Many of us are mad at Apple for a lot of good reasons, but please don’t let the process of venting that anger tar the goals and achievements of Open Prioritization.
Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:
- use custom elements (for modular HTML without frameworks)
- match pages with files (to avoid routing and simplify architecture)
- stick to standards (to avoid obsolescence and framework fatigue)
Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!
Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.
create-react-appas the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.
The transcript from the latest episode of the HTTP 203 podcast is well worth perusing.
- Internet Explorer halted development, no innovation. Would you say Safari is the new IE?
- There was loads of stuff missing. Is Safari the new IE?
- My early career was built on knowing the bugs in IE6 and how to solve them. Is Safari the new IE?
- Internet Explorer had a fairly cavalier attitude towards web standards. Is Safari the new IE?
- Back in the day that we had almost no communication whatsoever. Is Safari the new IE?
- Slow-release cycle. Is Safari the new IE?
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.
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.
This is a great talk by Hidde, looking at the history and evolution of cascading style sheets. Right up my alley!
Matthias has a good solution for dealing with the behaviour of CSS custom properties I wrote about: first set your custom properties with the fallback and then use feature queries (
@supports) to override those values.
Some great practical examples of progressive enhancement on one website:
- using grid layout in CSS,
- using the
pictureelement to provide
webpimages in HTML.
All of those enhancements work great in modern browsers, but the underlying functionality is still available to a browser like Opera Mini on a feature phone.
It’s now easier than ever to style form controls without sacrificing semantics and accessibility:
The reason is that we can finally style the ::before and ::after pseudo-elements on the
<input>tag itself. This means we can keep and style an
<input>and won’t need any extra elements. Before, we had to rely on the likes of an extra
<span>, to pull off a custom design.
The demo is really nice. And best of all, you can wrap all of these CSS enhancements in a feaure query:
Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to
Excellent news! All the major browsers have agreed to freeze their user-agent strings, effectively making them a relic (which they kinda always were).
For many (most?) uses of UA sniffing today, a better tool for the job would be to use feature detection.