Firefox as the asphyxiating canary in the coalmine of the web.
A really deep dive into flexbox. This is a great example of what I categorise as “thinking like a browser” (a skill I recommend for any front-end developer).
This is something I bump against over and over again: so-called evergreen browsers that can’t actually be updated because of operating system limits.
From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.
But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
So I had two older browsers that couldn’t be updated. It was device obsolescence because you couldn’t install the latest browser.
Websites stop working and the only solution is to buy a whole new device.
The web historically moves in waves.
Libraries are created to push complex features in an easier way. Then the libraries themselves get complicated, often more so than the benefits they provide.
Eventually, (some of) the core features of those libraries make their way into the browser itself, but the libraries linger like water on the shore, slowly receding.
And before the sand has a chance to fully dry, a new set of libraries washes in to push the web even further.
Prompted by my talk, The State Of The Web, Brian zooms out to get some perspective on how browser power is consolidated.
The web is made of clients and servers. There’s a huge amount of diversity in the server space but there’s very little diversity when it comes to clients because making a browser has become so complex and expensive.
But Brian hopes that this complexity and expense could be distributed amongst a large amount of smaller players.
10 companies agreeing to invest $10k apiece to advance and maintain some area of shared interest is every bit as useful as 1 agreeing to invest $100k generally. In fact, maybe it’s more representative.
We believe that there is a very long tail of increasingly smaller companies who could do something, if only they coordinated to fund it together. The further we stretch this out, the more sources we enable, the more its potential adds up.
What I want instead is an anarchist web browser.
Throw away everything and start again and focus intensely about what people care about when it comes to the web.
Ah, this brings back memories of hacking on the WorldWideWeb project at CERN!
(Not the original one. I’m not that old. I mean the recreation.)
At first glance, this looks like a terrible idea. But the key is in the implementation. In this case, the implementation is truly awful.
The section on detecting “auto dark theme” is, as far as I can tell, not intended as a joke.
Mind you, this could all be a galaxy-brain idea to encourage more developers to provide their own dark mode styles. (In much the same way that AMP was supposed to encourage better performance.)
Keep this link handy to share with your boss or client. It is almost certainly not worth your while optimising for Internet Explorer.
Note: Google aren’t turning IE users away. Instead they’ll get a reduced scriptless experience. That’s the way to do it. Remember:
nomodule are your friends for cutting the mustard.
Importantly, Google has not simply cut off Internet Explorer 11 from using Google Search, leaving people unable to search the web. Instead, Internet Explorer customers are now shown a rudimentary “fallback experience” for Google Search, which can perform basic searches but isn’t as fully featured as Google is on modern browsers.
If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!
I have this expensive computer in my pocket and it feels unfair that it is hamstrung in this very specific way of not allowing other browser engines. I also have an Apple laptop and it’s not hamstrung in that way, and I really hope it never is.
You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.
A terrific in-depth look at the frustrating state of the web on iOS.
So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.
And this damning assessment is mercifully free of conspiracy theories.
The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.
Google is focussing on improving the web by making it more capable.
Safari seems to focus on improving the web as it currently is.
Read the whole thing—it’s excellent!
There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.
The excellent (and cheap!) State Of The Browser is coming back to Conway Hall this year on Saturday, October 30th. Speakers include Rachel Andrew and Amber Case.
Everyone needs to show proof of vaccination or a negative Covid test to get into the venue, which is reassuring.
I think I’m gonna go!
I knew that custom properties don’t work in media queries but I had no idea that there was such a thing as custom media queries, which effectively do the same thing.
But this is not implemented in any browser. Boo! This would be so useful! If browser makers can overcame the technical hurdles with container queries, I’m sure they can deliver custom media queries.
Bruce Lawson’s personal site : Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps
Following on from Stuart’s, here’s Bruce’s presentation to the CMA on Apple’s monopolistic practices and hostility to progressive web apps.
What I would like is that I can give users the best experience on the web, on the best mobile hardware. That best mobile hardware is Apple’s, but at the moment if I want to choose Apple hardware I have to choose a sub-par web experience. Nobody can fix this other than Apple, and there are a bunch of approaches that they could take — they could make Safari be a best-in-class experience for the web, or they could allow other people to collaborate on making the browser best-in-class, or they could stop blocking other browsers from their hardware. People have lots of opinions about which of these, or what else, could and should be done about this; I think pretty much everyone thinks that something should be done about it, though.
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.
A wonderful bit of spelunking into the annals of software interfaces by Elise Blanchard.