Tags: frontend



Wednesday, January 26th, 2022

Here’s what I didn’t know about :where() - Manuel Matuzović

I feel like I’m starting to understand how the CSS :where pseudo-class works and why it’s useful. The cogs are slowly turning in my brain.

Monday, January 24th, 2022

No, Apple Did Not Crowdfund :focus-visible in Safari – Eric’s Archived Thoughts

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.

Thursday, January 20th, 2022


I wrote about how I created a page on The Session with instructions for installing the site to your home screen. When I said that I included screenshots on that page, I may have underplayed the effort involved. It was real faff.

I’ve got an iPhone so generating screenshots (and video) from that wasn’t too bad. But I don’t have access to an Android phone. I found myself scouring the web for templates that I could use to mockup a screenshot of the address bar.

That got me thinking…

Wouldn’t it be cool if there were a service that generated those screenshots for you? You give it a URL, and it spits out screenshots of the site complete with overlays showing the installation flow on Android and iOS. It could even generate the img markup, complete with differently-scaled images for the srcset attribute.

Download the images. Copy that markup. Paste it into a page on your site. Boom! Now you’ve got somewhere to point your visitors to if you’d like them to install your progressive web app.

There are already some services out there for generating screenshots of mobile phones but they’re missing is the menu overlays for adding to home screen.

The devrels at both Google and Microsoft have been doing a great job of promoting progressive web apps. They’ve built tools to help you with tasks like generating icons or creating your web app manifest. It would be sooooo nifty if those tools also generated instructional screenshots for adding to home screen!

Tuesday, January 18th, 2022

Installing progressive web apps

I don’t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don’t play the game myself, I think it’s pretty great.

Not only does Wordle have a very sweet backstory, but it’s also unashamedly on the web. If you want to play, you go to the URL powerlanguage.co.uk/wordle. That’s it. No need to download an app.

That hasn’t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.

Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don’t believe it has offline support). That’s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.

Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it’s great to see this knowledge being spread. On the other hand it’s dispiriting that it’s even necessary to tell people that they can do this, like it’s a hidden nerdy secret just for power users.

At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?

Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.

That’s what I’ve done on thesession.org. I’ve published a page on how to install The Session to your home screen.

On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.

The menu icon on Android. The share icon on iOS.

When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.

I’ve included screenshots to help people identify these mysterious portals. For iOS I’ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.

I’ve linked to the page with the installation instructions from the site’s “help” page and the home page.

Handy tip: when you’re adding a start_url value to your web app manifest, it’s common to include a query string like this:

start_url: "/?homescreen"

I’m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don’t do analytics on The Session but I’m still using that query string in my start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don’t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn’t see that message when they launch The Session.

If you’ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site’s visitors. You’d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.

Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there’s an emoji you could potentially use: 📲

It’s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.

(I’m not really serious about using that emoji, but if you do, be sure to use a sensible aria-label value on the enclosing a element.)

Thursday, January 13th, 2022

Partnering with Google on web.dev

When the web.dev team at Google contacted Clearleft about writing a course on responsive design, our eyes lit up.

This was clearly a good fit. For one thing, Clearleft has been pioneering responsive design from day one—we helped launch some of the first responsive sites in the UK. But there was another reason why this partnership sounded good: we had the same approach to writing and sharing.

Ever since Clearleft was founded in 2005 we’ve taken on board the motto of the World Wide Web itself: let’s share what we know. As well as doing the work, we enjoy sharing how the work gets done. Whether it’s case studies, blog posts, podcasts, or conference talks, we’re always thinking about ways to contribute to the web community.

Many other great resources have contributed to our collective knowledge: A List Apart, CSS Tricks, Smashing Magazine, Mozilla Developer Network, and more recently web.dev, which has become an excellent resource for front-end developers. But they wanted to make sure that designers were also included. Una described her plan for a fifteen-part course on modern responsive design aimed at web designers.

It was ambitious. The plan included some cutting edge technology that’s just shipping in browsers now. It sounded daunting and exciting in equal measure. Mostly it sounded like far too good an opportunity for Clearleft to pass up so we jumped on it.

With my fellow Clearlefties otherwise engaged in client work, it fell to me to tap out the actual words. Fortunately I’ve had plenty of experience with my own website of moving my fingers up and down on a keyboard in attempt to get concepts out of my head and onto the screen. I familiarised myself with the house style and got to work.

I had lots of help from the Chrome developer relations team at Google. Project management (thanks, Terry!), technical editing (thanks, Adam!), and copy editing (thanks, Rachel!) were provided to me.

Working with Rachel again was a real treat—she wrote the second edition of my book, HTML5 For Web Designers. Every time she suggested a change to something I had written, I found myself slapping my forehead and saying “Of course! That’s so much better!” It felt great to have someone else be a content buddy for me.

We had a weekly video call to check in and make sure everything was on track. There was also an epic spreadsheet to track the flow of each module as they progressed from outline to first draft to second draft.

Those were just the stages when the words were in a Google doc. After that, the content moved to Github and there was a whole other process to shepherd it towards going live.

Take note of the license in that repo: Creative Commons Attribution 3.0. That means that you—or anyone—is free to use and reuse all the material (as long as you include a credit). I think I might republish the fifteen articles on my site at some point.

If you’d like to peruse the outcome of this collaboration between Clearleft and Google, head on over to web.dev and learn responsive design. Then feel free to share it!

  1. Introduction
  2. Media queries
  3. Internationalization
  4. Macro layouts
  5. Micro layouts
  6. Typography
  7. Responsive images
  8. The picture element
  9. Icons
  10. Theming
  11. Accessibility
  12. Interaction
  13. User interface patterns
  14. Media features
  15. Screen configurations

Wednesday, January 12th, 2022

Media queries with display-mode

It’s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.

I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.

Best of all, I got to put my new-found knowledge to use! Here’s how…

The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.

In the web app manifest file for The Session, the display-mode property is set to “standalone.” That means it will launch without any browser chrome: no address bar and no back button. It’s up to me to provide the functionality that the browser usually takes care of.

So I added a back button in the navigation interface. It only appears on small screens.

Do you see the assumption I made?

I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?

Nope. If you’re using Chrome or Edge on a desktop device, you will be actively encourged to “install” The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.

So desktop users who install the progressive web app don’t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).

I was alerted to this issue on The Session:

It downloaded for me but there’s a bug, Jeremy - there doesn’t seem to be a way to go back.

Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:

.goback {
  display: none;
@media (display-mode: standalone) {
  .goback {
    display: inline;

Now the back button shows up if you “install” The Session, regardless of whether that’s on mobile or desktop.

Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?

If I hadn’t been writing about media features, I don’t think I would’ve been able to solve the problem. It’s a really good feeling when you’ve just learned something new, and then you immediately find exactly the right use case for it!

Tuesday, January 11th, 2022

The monoculture web

Firefox as the asphyxiating canary in the coalmine of the web.

Saturday, January 8th, 2022

Ban embed codes

Prompted by my article on third-party code, here’s a recommendation to ditch any embeds on your website.

How Flexbox Works

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).

The Optional Chaining Operator, “Modern” Browsers, and My Mom - Jim Nielsen’s Blog

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.

Thursday, January 6th, 2022

Today, the distant future

It’s a bit of a cliché to talk about living in the future. It’s also a bit pointless. After all, any moment after the big bang is a future when viewed from any point in time before it.

Still, it’s kind of fun when a sci-fi date rolls around. Like in 2015 when we reached the time depicted in Back To The Future 2, or in 2019 when we reached the time of Blade Runner.

In 2022 we are living in the future of web standards. Again, technically, we’re always living in the future of any past discussion of web standards, but this year is significant …in a very insignificant way.

It all goes back to 2008 and an interview with Hixie, editor of the HTML5 spec at the WHATWG at the time. In it, he mentioned the date 2022 as the milestone for having two completely interoperable implementations.

The far more important—and ambitious—date was 2012, when HTML5 was supposed to become a Candidate Recommendation, which is standards-speak for done’n’dusted.

But the mere mention of the year 2022 back in the year 2008 was too much for some people. Jeff Croft, for example, completely lost his shit (Jeff had a habit of posting angry rants and then denying that he was angry or ranty, but merely having a bit of fun).

The whole thing was a big misunderstanding and soon irrelevant: talk of 2022 was dropped from HTML5 discussions. But for a while there, it was fascinating to see web designers and developers contemplate a year that seemed ludicriously futuristic. Jeff wrote:

God knows where I’ll be in 13 years. Quite frankly, I’ll be pretty fucking disappointed in myself (and our entire industry) if I’m writing HTML in 13 years.

That always struck me as odd. If I thought like that, I’d wonder what the point would be in making anything on the web to begin with (bear in mind that both my own personal website and The Session are now entering their third decade of life).

I had a different reaction to Jeff, as I wrote in 2010:

Many web developers were disgusted that such a seemingly far-off date was even being mentioned. My reaction was the opposite. I began to pay attention to HTML5.

But Jeff was far from alone. Scott Gilbertson wrote an angry article on Webmonkey:

If you’re thinking that planning how the web will look and work 13 years from now is a little bit ridiculous, you’re not alone.

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

(I’m re-reading that article in the current version of Firefox: 95.0.2.)

Brian Veloso wrote on his site:

Two-thousand-twenty-two. That’s 14 years from now. Can any of us think that far? Wouldn’t our robot overlords, whether you welcome them or not, have taken over by then? Will the internet even matter then?

From the comments on Jeff’s post, there’s Corey Dutson:

2022: God knows what the Internet will look like at that point. Will we even have websites?

Dan Rubin, who has indeed successfully moved from web work to photography, wrote:

I certainly don’t intend to be doing “web work” by that time. I’m very curious to see where the web actually is in 14 years, though I can’t imagine that HTML5 will even get that far; it’ll all be obsolete before 2022.

Joshua Works made a prediction that’s worryingly close to reality:

I’ll be surprised if website-as-HTML is still the preferred method for moving around the tons of data we create, especially in the manner that could have been predicted in 2003 or even today. Hell, iPods will be over 20 years old by then and if everything’s not run as an iPhone App, then something went wrong.

Someone with the moniker Grand Caveman wrote:

In 2022 I’ll be 34, and hopefully the internet will be obsolete by then.

Perhaps the most level-headed observation came from Jonny Axelsson:

The world in 2022 will be pretty much like the world in 2009.

The world in 2009 is pretty much like 1996 which was pretty much like the world in 1983 which was pretty much like the world in 1970. Some changes are fairly sudden, others are slow, some are dramatic, others subtle, but as a whole “pretty much the same” covers it.

The Web in 2022 will not be dramatically different from the Web in 2009. It will be less hot and it will be less cool. The Web is a project, and as it succeeds it will fade out of our attention and into the background. We don’t care about things when they work.

Now that’s a sensible perspective!

So who else is looking forward to seeing what the World Wide Web is like in 2036?

I must remember to write a blog post then and link back to this one. I have no intention of trying to predict the future, but I’m willing to bet that hyperlinks will still be around in 14 years.

Speaking of long bets…

Tuesday, January 4th, 2022

The UI fund

This is an excellent initiate spearheaded by Nicole and Sarah at Google! They want to fund research into important web UI work: accessibility, form controls, layout, and so on. If that sounds like something you’ve always wanted to do, but lacked the means, fill in the form.

Monday, January 3rd, 2022

Start at the beginning: the importance of learning the basics - localghost

I’d recommend going in the order HTML, CSS, JS. That way, you can build something in HTML, add CSS to it as you learn it, and finally soup it up with your new-found JS knowledge.

Excellent advice for anyone new to web develoment.

Once you start getting into interactive website territory, with API calls and fancy stuff, that’s where you need JavaScript (JS) knowledge. More specifically, vanilla JS: plain JS with no additional frameworks or plugins. The JS that your browser understands without having to do any pre-processing. It makes working with frameworks a whole lot easier, and it’ll help you to know when not to use a framework (and avoid making users download massive JS bundles when all you need is a tiny bit of code).

Thursday, December 30th, 2021

Add Less | CSS-Tricks - CSS-Tricks

Let the power of the browser work for you, and use less stuff!


Your websites start fast until you add too much to make them slow. Do you need any framework at all? Could you do what you want natively in the browser?

Wednesday, December 29th, 2021

Add a Service Worker to Your Site | CSS-Tricks - CSS-Tricks

Damn, I wish I had thought of giving this answer to the prompt, “What is one thing people can do to make their website better?”

If you do nothing else, this will be a huge boost to your site in 2022.

Chris’s piece is a self-contained tutorial!

Thursday, December 23rd, 2021

Even more writing on web.dev

The final five are here! The course on responsive design I wrote for web.dev is now complete, just in time for Christmas. The five new modules are:

  1. Accessibility
  2. Interaction
  3. User interface patterns
  4. Media features
  5. Screen configurations

These five felt quite “big picture”, and often quite future-facing. I certainly learned a lot researching proposals for potential media features and foldable screens. That felt like a fitting way to close out the course, bookending it nicely with the history of responsive design in the introduction.

And with that, the full course is now online. Go forth and learn responsive design!

Thursday, December 16th, 2021

Tailwind and the Femininity of CSS

So when it comes down to the root of the problem, perhaps it isn’t CSS itself but our unwillingness to examine our sexist ideas of what is worthy in web development.

Wednesday, December 15th, 2021

Tuesday, December 14th, 2021

Defensive CSS - Ahmad Shadeed

This is a smart collection of situations to consider and the CSS to resolve them. It’s all about unearthing assumptions.

Monday, December 13th, 2021

Serve folder for web development

This is a very nifty use of a service worker—choose a local folder that you want to navigate using HTTP rather than the file system.