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.
I really enjoyed talking to Sydney Lai about progressive web apps, resilient web design, and all my other hobby horses.
Alas, there’s no transcript and I can’t find a direct link to the RSS feed or the individual audio file on the podcast website so it’s not huffduffable.
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.
I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.
When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.
Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.
Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.
Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.
A lot of what he says really resonates with me. Over and over again I’ve seen projects where the technical decison around which monolithic client-side JavaScript framework to use has been made even before a problem has been defined.
Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.
The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.
It’s always humans.
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)
- use the in-browser package manager (for JavaScript packages without build tools)
- 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.
I have a special disdain for beginner JavaScript tutorials that have you run
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 annual day-long online accessibility event is back on September 23rd.
No sign-up. No registration. All sessions are streamed live and publicly on the Inclusive Design 24 YouTube channel.
This detailed proposal from Miriam for scoping CSS is well worth reading—it makes a lot of sense to me.
…you would be forgiven if you saw an API where a feature went from green (supported) to red (unsupported) and you thought: is the browser being deprecated?
That’s the idea behind my new shiny domain: canistilluse.com. I made the site as satire after reading Jeremy Keith’s insightful piece where he notes:
the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
It’s weirdly gratifying to see a hastily-written sarcastic quip tuned into something real.
Apparently the sentence forms that I kicked off with Huffduffer are making a comeback.
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 6, it had a really slow JavaScript engine, performance was bad in that browser. 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?
I’m very excited about this proposal for animating transitions between web pages!
I’m less excited about doing it for single page apps, but I get why it’s the simplest place to start.
This builds on Jake’s earlier proposal which I always thought was excellent and much needed. I’m not the only one. Chris agrees.
I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.
But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:
I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.
It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.
On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.
And the verdict? Well, you’ll just to have to listen to the podcast episode.
If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.
When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.
Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).
I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.
Update: the bug with that episode of the HTTP 203 podcast has been fixed. Here’s the transcript! And all future episodes will have transcripts too:
Some folks called us out for lacking transcripts for our podcasts. Fair point! So, here we go (and all future episodes will have transcripts)https://t.co/HmfwBvAicA
— Jake Archibald (@jaffathecake) August 18, 2021
After I jotted down some quick thoughts last week on the disastrous way that Google Chrome rolled out a breaking change, others have posted more measured and incisive takes:
In fairness to Google, the Chrome team is receiving the brunt of the criticism because they were the first movers. Mozilla and Apple are on baord with making the same breaking change, but Google is taking the lead on this.
As I said in my piece, my issue was less to do with whether confirm(), prompt(), and alert() should be deprecated but more to do with how it was done, and the woeful lack of communication.
Thinking about it some more, I realised that what bothered me was the lack of an upgrade path. Considering that dialog is nowhere near ready for use, it seems awfully cart-before-horse-putting to first remove a feature and then figure out a replacement.
I was chatting to Amber recently and realised that there was a very different example of a feature being deprecated in web browsers…
We were talking about the KeyboardEvent.keycode property. Did you get the memo that it’s deprecated?
But fear not! You can use the KeyboardEvent.code property instead. It’s much nicer to use too. You don’t need to look up a table of numbers to figure out how to refer to a specific key on the keyboard—you use its actual value instead.
So the way that change was communicated was:
Hey, you really shouldn’t use the
keycodeproperty. Here’s a better alternative.
But with the more recently change, the communication was more like:
Hey, you really shouldn’t use
confirm(),prompt(), oralert(). So go fuck yourself.
It’s not just a story about unloved APIs, it’s a story about power, standards design, and who owns the platform — and it makes me afraid for the future of the web.
A thoughtful, considered post by Rich Harris on the whole ballyhoo with alert and its ilk:
For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow’s spec wranglers, is a world in which the web has already lost.
Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.
With any changes to the platform, but especially breaking ones, communication and feedback on how this will impact people who actually build things with the web is super important, and that was not done here.
Chris has written a thoughtful reflection on last week’s brouhaha around confirm, prompt, and alert being deprecated in Chrome. The way that the “developer relations” folks at Google handled feedback was less than ideal.
I reached out to one of the Google Chrome developer advocates I know to see if I could learn more. It did not go well.
I mentioned recently that there might be quite a difference in tone between my links and my journal here on my website:
’Sfunny, when I look back at older journal entries they’re often written out of frustration, usually when something in the dev world is bugging me. But when I look back at all the links I’ve bookmarked the vibe is much more enthusiastic, like I’m excitedly pointing at something and saying “Check this out!” I feel like sentiment analyses of those two sections of my site would yield two different results.
My journal entries have been even more specifically negative of late. I’ve been bitchin’ and moanin’ about web browsers. But at least I’m an equal-opportunities bitcher and moaner.
I wish my journal weren’t so negative, but my mithering behaviour has been been encouraged. On more than one occasion, someone I know at a browser company has taken me aside to let me know that I should blog about any complaints I might have with their browser. It sounds counterintuitive, I know. But these blog posts can give engineers some ammunition to get those issues prioritised and fixed.
So my message to you is this: if there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it.
Publish it on your website. You could post your gripes on Twitter but whinging on Jack’s website is just pissing in the wind. And I suspect you also might put a bit more thought into a blog post on your own site.
I know it’s a cliché to say that browser makers want to hear from developers—and I’m often cynical about it myself—but they really do want to know what we think. Share your thoughts. I’ll probably end up linking to what you write.
It feels like the web we’re making now is a web designed for commercial interests.
If the web is “for everyone”, how and where are “everyone’s” interested being represented?
Browsers are not an enterprise of the people. We do not elect our browser representatives who decide what a browser is and is not.
There was quite a kerfuffle recently about a feature being removed from Google Chrome. To be honest, the details don’t really matter for the point I want to make, but for the record, this was about removing alert and confirm dialogs from cross-origin iframes (and eventually everywhere else too).
It’s always tricky to remove a long-established feature from web browsers, but in this case there were significant security and performance reasons. The problem was how the change was communicated. It kind of wasn’t. So the first that people found out about it about was when things suddenly stopped working (like CodePen embeds).
The Chrome team responded quickly and the change has now been pushed back to next year. Hopefully there will be significant communication before that to let site owners know about the upcoming breakage.
So all’s well that ends well and we’ve all learned a valuable lesson about the importance of communication.
Or have we?
While this was going on, Emily Stark tweeted a more general point about breakage on the web:
Breaking changes happen often on the web, and as a developer it’s good practice to test against early release channels of major browsers to learn about any compatibility issues upfront.
Yikes! To me, this appears wrong on almost every level.
First of all, breaking changes don’t happen often on the web. They are—and should be—rare. If that were to change, the web would suffer massively in terms of predictability.
Secondly, the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
I wasn’t the only one surprised by this message.
No, no, no, no! One of the best things about developing for the web is that, as a rule, browsers don’t break old code. Expecting every website and application to have an active team of developers maintaining it at all times is not how the web should work!
Most organizations and individuals do not have the resources to properly test and debug their website against Chrome canary every six weeks. Anybody who published a spec-compliant website should be able to trust that it will keep working.
This statement seriously undermines my trust in Google as steward for the web platform. When did we go from “never break the web” to “yes we will break the web often and you should be prepared for it”?!
It’s worth pointing out that the original tweet was not an official Google announcement. As Emily says right there on her Twitter account:
Opinions are my own.
Still, I was shaken to see such a cavalier attitude towards breaking changes on the World Wide Web. I know that removing dangerous old features is inevitable, but it should also be exceptional. It should not be taken lightly, and it should certainly not be expected to be an everyday part of web development.
It’s almost miraculous that I can visit the first web page ever published in a modern web browser and it still works. Let’s not become desensitised to how magical that is. I know it’s hard work to push the web forward, constantly add new features, while also maintaining backward compatibility, but it sure is worth it! We have collectively banked three decades worth of trust in the web as a stable place to build a home. Let’s not blow it.
If you published a website ten or twenty years ago, and you didn’t use any proprietary technology but only stuck to web standards, you should rightly expect that site to still work today …and still work ten and twenty years from now.
There was something else that bothered me about that tweet and it’s not something that I saw mentioned in the responses. There was an unspoken assumption that the web is built by professional web developers. That gave me a cold chill.
The web has made great strides in providing more and more powerful features that can be wielded in learnable, declarative, forgiving languages like HTML and CSS. With a bit of learning, anyone can make web pages complete with form validation, lazily-loaded responsive images, and beautiful grids that kick in on larger screens. The barrier to entry for all of those features has lowered over time—they used to require JavaScript or complex hacks. And with free(!) services like Netlify, you could literally drag a folder of web pages from your computer into a browser window and boom!, you’ve published to the entire world.
But the common narrative in the web development community—and amongst browser makers too apparently—is that web development has become more complex; so complex, in fact, that only an elite priesthood are capable of making websites today.
Absolute bollocks.
You can choose to make it really complicated. Convince yourself that “the modern web” is inherently complex and convoluted. But then look at what makes it complex and convoluted: toolchains, build tools, pipelines, frameworks, libraries, and abstractions. Please try to remember that none of those things are required to make a website.
This is for everyone. Not just for everyone to consume, but for everyone to make.