Everything you ever wanted to know about
Monday, May 4th, 2020
Everything you ever wanted to know about
Friday, May 1st, 2020
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.
A collection of articles and talks about HTML, CSS, and JS, grouped by elements, attributes, properties, selectors, methods, and expressions.
Tuesday, April 28th, 2020
Monday, April 27th, 2020
The cost of “modern” web development:
We’re dealing with the results of bad defaults, deployed at a terrible scale.
Frankly, it’s hard for me not to see this as a failure of governance. Our industry is, by and large, self-regulated. And right now, producing quality work relies on teams electing to adopt best practices.
Last week I wrote about the great work that Matthew did and now he’s written up his process:
Thursday, April 23rd, 2020
It’s been fascinating to see how television programmes have adapted to The Situation. It’s like there’s been a weird inversion with the YouTube asthetic. Instead of YouTubers doing their utmost to emulate the look of professional television, now everyone on professional television looks like a YouTuber.
No more lighting or audio technicians. No more studio audiences. Heck, no more studios.
There are some kinds of TV programmes that are showing the strain. A lot of comedy formats just fall flat without the usual production values. But a lot of programmes work just fine. In fact, some of them might be better. Watching Mary Beard present Front Row Late from her house is an absolute delight. It feels more direct and honest without the artiface of a television studio. It kind of makes you wonder whether expensive production costs are really necessary when what you really care about is the content.
All of this is one big belaboured metaphor for websites.
In times of crisis, informational websites sometimes offer a “lite” version. Max has even made an emergency website kit:
The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.
Eric emphasises the importance of performance in his post Get Static:
I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.
Tom Loosemore offers this advice to teams building new coronavirus services:
- Get a 4 year-old Android phone, and use it as your test/demo device.
- https://design-system.service.gov.uk is your friend.
- Full React isn’t your friend if it makes your service slow & inaccessible
Remember: This is for everyone.
Indeed, Gov.uk are usually a paragon of best practices in just about any situation. But they dropped the ball recently, as Matthew attests:
One sign that your website isn’t meeting the needs of all your users is when Matthew Somerville gets sufficiently grumpy about it to do a proper version himself.
It’s true enough that Matthew excels at creating lightweight, accessible versions of services that are too bloated or buggy to use. His accessible Odeon project from back in the day is legendary. And I use his slimline version of the National Rail website all the time: traintimes.org.uk—it’s a terrificly performant progressive web app.
Maybe now, with this rush to make lightweight versions of valuable services, we might stop and reflect on whether we ever really needed all those added extras in the first place.
Hope springs eternal.
Update: Matthew has written about his process in Looking at coronavirus.data.gov.uk.
Excellent in-depth research by Tim on how the major frameworks affect performance. There are some surprising (and some unsurprising) findings in here.
I wish with all my heart that this data would have some effect but I fear there’s an entire culture of “modern” web development that stick its fingers in its ears and say “La, la, la, I can’t hear you.”
Monday, April 20th, 2020
I love how Remy explains front-end development to his kids:
The bones are the HTML. Each bone has a name, we call them tags (or elements).
…the skin and the paint on the skin, this is CSS.
Wednesday, April 8th, 2020
Consider what React and other SPA frameworks are good for: stateful, extensible component-driven applications. Now consider what a résumé’s goals are.
Thursday, April 2nd, 2020
Mike sees the church of JS-first ignoring the lessons to be learned from the years of experience accumulated by CSS practitioners.
As the responsibilities of front-end developers have become more broad, some might consider the conventions outlined here to be not worth following. I’ve seen teams spend weeks planning the right combination of framework, build tools, workflows and patterns only to give zero consideration to the way they architect UI components. It’s often considered the last step in the process and not worthy of the same level of consideration.
It’s important! I’ve seen well-planned project fail or go well over budget because the UI architecture was poorly planned and became un-maintainable as the project grew.
Monday, March 30th, 2020
This is a great way to organise code snippets—listed by use case, and searchable too!
Next time you’re stuck on some DOM scripting, before reaching for a framework or library, check here first.
Tuesday, March 24th, 2020
I wrote yesterday about how messing about on your own website can be a welcome distraction. I did some tinkering with adactio.com on the weekend that you might be interested in.
Let me set the scene…
I’ve started recording and publishing a tune a day. I grab my mandolin, open up Quicktime and make a movie of me playing a jig, a reel, or some other type of Irish tune. I include a link to that tune on The Session and a screenshot of the sheet music for anyone who wants to play along. And I embed the short movie clip that I’ve uploaded to YouTube.
iframe has been delivered for nothing.
Meanwhile over on The Session, I’ve got a strategy for embedding YouTube videos that’s better for performance. Whenever somebody posts a link to a video on YouTube, the thumbnail of the video is embedded. Only when you click the thumbnail does that image get swapped out for the
iframe with the video.
That’s what I needed to do here on adactio.com.
That code checks to see if the URL is from a service that provides an oEmbed endpoint. A what-Embed? oEmbed!
In this case
http://example.com/oembed is the endpoint and
url is the value of a URL from that provider. Here’s a real life example from YouTube:
https://www.youtube.com/oembed is the endpoint and
url is the address of any video on YouTube.
You get back some JSON with a pre-defined list of values like
html payload is the markup for your embed code.
By default, YouTube sends back markup like this:
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
But now I want to use an
img instead of an
iframe. One of the other values returned is
thumbnail_url. That’s the URL of a thumbnail image that looks something like this:
In fact, once you know the ID of a YouTube video (the
?v= bit in a YouTube URL), you can figure out the path to multiple images of different sizes:
- 120 × 90:
- 320 × 180:
- 480 × 360:
- 1280 × 720:
(Although that last one—
maxresdefault.jpg—might not work for older videos.)
Okay, so I need to extract the ID from the YouTube URL. Here’s the PHP I use to do that:
parse_str(parse_url($url, PHP_URL_QUERY), $arguments);
$id = $arguments['v'];
Then I can put together some HTML like this:
<a class="videoimglink" href="'.$url.'">
<img width="100%" loading="lazy"
Over on The Session, I’m using
addEventListener but here on adactio.com I’m going to be dirty and listen for the event directly in the markup using the
When the link is clicked, I nuke the link and the image using
innerHTML. This injects an iframe where the link used to be (by updating the
innerHTML value of the link’s
But notice that I’m not using the default YouTube URL for the iframe. That would be:
Instead I’m swapping out the domain
I can’t remember where I first came across this undocumented parallel version of YouTube that has, yes, you guessed it, no cookies. It turns out that, not only is the default YouTube embed code bad for performance, it is—unsurprisingly—bad for privacy too. So the
youtube-nocookie.com domain can protect your site’s visitors from intrusive tracking. Pass it on.
Anyway, I’ve got the markup I want now:
<a class="videoimglink" href="https://www.youtube.com/watch?v=-eiqhVmSPcs"
<img width="100%" loading="lazy"
alt="The Banks Of Lough Gowna (jig) on mandolin"
The functionality is all there. But I want to style the embedded images to look more like playable videos. Time to break out some CSS (this is why I added the
videoimglink class to the YouTube link).
I’m going to use generated content to create a play button icon. Because I can’t use generated content on an
img element, I’m applying these styles to the containing
I was going to make an SVG but then I realised I could just be lazy and use the unicode character instead.
Right. Time to draw the rest of the fucking owl:
top: calc(50% - 5vmax);
left: calc(50% - 5vmax);
That’s a bunch of instructions for sizing and positioning. I’d explain it, but that would require me to understand it and frankly, I’m not entirely sure I do. But it works. I think.
With a translucent play icon positioned over the thumbnail, all that’s left is to add a
:hover style to adjust the opacity:
Wheresoever thou useth
:hover, thou shalt also useth
Okay. It’s good enough. Ship it!
If you embed YouTube videos on your site, and you’d like to make them more performant, check out this custom element that Paul made: Lite YouTube Embed. And here’s a clever technique that uses the
srcdoc attribute to get a similar result (but don’t forget to use the
Tuesday, March 17th, 2020
I’m constantly forgetting the difference between the
async attribute and the
defer attribute on
script elements—this is a handy explanation.
Saturday, March 7th, 2020
Tuesday, March 3rd, 2020
Garrett’s observation is spot-on here:
Thursday, February 6th, 2020
As you may have noticed, I’m a fan of progressive enhancement.
It’s not cool. It’s often at odds with “modern” web development, so I end up looking like an old man yelling at a cloud to get off my lawn. Or something.
At its heart though, progressive enhancement seems fairly uncontroversial and inoffensive to me. It’s an approach. A mindset. Here’s how I describe it in Resilient Web Design:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
Progressive enhancement makes use of the principle of least power:
Choose the least powerful language suitable for a given purpose.
That’s step two of the three-step process. But the third step is vital.
I think a lot of the hostility towards progressive enhancement comes from a misunderstanding of that three-step process, perhaps thinking that it stops at step two. I’m sure that some have intrepreted progressive enhancement as preventing developers from using the latest and greatest technology. Nothing could be further from the truth!
But I was very heartened when I saw the pendulum start to swing back the other way a bit…
The idea is that subsequent navigations—which will happen with Ajax—should be snappy. But the price has already been paid by then. The initial loading experience is jagged and frustrating.
This use of server-side rendering followed by hydration feels like progressive enhancement, because it separates out the delivery of markup and scripts. But it’s missing the mindset.
I was a little disappointed to see Kyle Simpson—who I admire greatly—conflate separation of concerns with progressive enhancement in his talk from JSCamp 2019:
Anybody experienced that where you’ve been on a web page and it’s not really fully functional yet? I can see something but I can’t actually make any usage of it yet.
These are all things that cropped out of our thought process that said: “Let’s build the web in layers. Let’s deliver it progressively in layers. Because that’s morally right. We call this progressive enhancement. And let’s not worry too much about all these potential user experience flaws that may happen.”
That’s a spot-on description of server-side rendering and hydration, but it’s a gross mischaracterisation of progressive enhancement.
If people are equating progressive enhancement with thoughtless server-side rendering and hydration, then I can see why they’d be hostile towards it.
Users would be better served with unprogressive non-enhancement:
You take some structured content, which follows the vertical flow of the document in a way that everyone understands.
Which people traverse easily by either dragging their scroll bar with their mouse, or operating the keyboard using the up and down keys, or using the spacebar.
Or if they’re using a touch device, simply flicking backwards and forwards in that easy way that we’ve all become used to. What you do is you take that, and you fucking well leave it alone.
I beg to differ.
Hope is on the horizon for React in the form of partial hydration. I sincerely hope that it will become the default way of balancing server-side rendering with just-in-time client-side interaction.
The situation we have now is the worst of both worlds: server-side rendering followed by a tsunami of hydration. It has a whiff of progressive enhancement to it (because there’s a cosmetic separation of concerns) but it has none of the user benefits.
Monday, February 3rd, 2020
It’s wild because in engineering terms this question, how does it fail?, should be the first one we ask, but oftentimes it is never even considered in front-end development. A good example is most client-side JS frameworks that render the entire UI in the browser, how would your app or site fail in that situation?
This is a very important point:
It’s important not to try making the no-JS experience work like the full one. The interface has to be revisited. Some features might even have to be removed, or dramatically reduced in scope. That’s also okay. As long as the main features are there and things work nicely, it should be fine that the experience is not as polished.
I absolutely love this in-depth history of the web, written in a snappy, snarky tone.
In the beginning, there was no CSS.
This was very bad.
Even if you—like me—lived through all this stuff, I guarantee there’ll still be something in here you didn’t know.