Examples of defensive coding for CSS. This is an excellent mindset to cultivate!
Jeremy KeithMaking websites. Writing books. Speaking at events. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.
Journal 2711 Links 8835 Articles 76 Notes 5617
Tuesday, August 18th, 2020
Monday, August 17th, 2020
Design Principles For The Web—the links
I’m speaking today at an online edition of An Event Apart called Front-End Focus. I’ll be opening up the show with a talk called Design Principles For The Web, which ironically doesn’t have much of a front-end focus:
Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.
To avoid technical difficulties, I’ve pre-recorded the talk. So while that’s playing, I’ll be spamming the accompanying chat window with related links. Then I’ll do a live Q&A.
Should you be interested in the links that I’ll be bombarding the attendees with, I’ve gathered them here in one place (and they’re also on the website of An Event Apart). The narrative structure of the talk might not be clear from scanning down a list of links, but there’s some good stuff here that you can dive into if you want to know what the inside of my head is like.
- Page Weight Matters by Chris Zacharias
- Systems, Mistakes, and the Sea by Robin Rendle
- Patterns Day videos on Vimeo
- Workplace Topology by Danielle Huntrods
- The Design Squiggle by Damien Newman
- The Double Diamond by Design Council
- Canvassing a project by Andy Thornton
- How to run a premortem workshop by Rachel McConnell
- 5 Steps To Better Research by Benjamin Parry
- Design Principles collection
- Design Principles collection by Ben Brignell
- What makes a good design principle? by Matthew Ström
- Priority of Constituencies from HTML Design Principles
- The Eponymous Laws of Tech by Dave Rupert
- Principles of Design by Sir Tim Berners-Lee
- CERN 2019 WorldWideWeb Rebuild
- Data attributes and progressive enhancement by Derek Featherstone
- Government Design Principles by Government Digital Service
- Over-engineering is under-engineering by Baldur Bjarnason
- This Web App Best Viewed By Someone Else presentation by Eric Meyer on YouTube
- The top four web performance challenges
- Ubiquity and consistency
- Principles and priorities
- Putting design principles into action
Mind the gap
In May 2012, Brian LeRoux, the creator of PhoneGap, wrote a post setting out the beliefs, goals and philosophy of the project.
The beliefs are the assumptions that inform everything else. Brian stated two core tenets:
- The web solved cross platform.
- All technology deprecates with time.
That second belief then informed one of the goals of the PhoneGap project:
The ultimate purpose of PhoneGap is to cease to exist.
Last week, PhoneGap succeeded in its goal:
Since the project’s beginning in 2008, the market has evolved and Progressive Web Apps (PWAs) now bring the power of native apps to web applications.
Today, we are announcing the end of development for PhoneGap.
I think Brian was spot-on with his belief that all technology deprecates with time. I also think it was very astute of him to tie the goals of PhoneGap to that belief. Heck, it’s even in the project name: PhoneGap!
I recently wrote this about Sass and clamp:
jQuery is the perfect example of this. jQuery is no longer needed because cross-browser DOM Scripting is now much easier …thanks to jQuery.
Successful libraries and frameworks point the way. They show what developers are yearning for, and that’s where web standards efforts can then focus. When a library or framework is no longer needed, that’s not something to mourn; it’s something to celebrate.
That’s particularly true if the library of code needs to be run by a web browser. The user pays a tax with that extra download so that the developer gets the benefit of the library. When web browsers no longer need the library in order to provide the same functionality, it’s a win for users.
In fact, if you’re providing a front-end library or framework, I believe you should be actively working towards making it obselete. Think of your project as a polyfill. If it’s solving a genuine need, then you should be looking forward to the day when your code is made redundant by web browsers.
One more thing…
I think it was great that Brian documented PhoneGap’s beliefs, goals and philosophy. This is exactly why design principles can be so useful—to clearly set out the priorities of a project, so that there’s no misunderstanding or mixed signals.
If you’re working on a project, take the time to ask yourself what assumptions and beliefs are underpinning the work. Then figure out how those beliefs influence what you prioritise.
Ultimately, the code you produce is the output generated by your priorities. And your priorities are driven by your purpose.
You can make those priorities tangible in the form of design principles.
You can make those design principles visible by publishing them.
Netlify redirects and downloads
Making the Clearleft podcast is a lot of fun. Making the website for the Clearleft podcast was also fun.
Design wise, it’s a riff on the main Clearleft site in terms of typography and general layout. On the development side, it was an opportunity to try out an exciting tech stack. The workflow goes something like this:
- Open a text editor and type out HTML and CSS.
Comparing this to other workflows I’ve used in the past, this is definitely the most productive way of working. Some stats:
- Time spent setting up build tools: 00:00
- Time spent wrangling the pipeline to do exactly what you want: 00:00
- Time spent trying to get the damn build tools to work again when you return to the project after leaving it alone for more than a few months: 00:00:00
I have some files. Some images, three font files, a few pages of HTML, one RSS feed, one style sheet, and one minimal service worker script. I don’t need a web server to do anything more than serve up those files. No need for any dynamic server-side processing.
Netlify suits my hosting needs nicely. It also provides the added benefit that, should I need to update my CSS, I don’t need to add a query string or anything to the
link elements in the HTML that point to the style sheet: Netlify does cache invalidation for you!
The mp3 files of the actual podcast episodes are stored on S3. I link to those mp3 files from
enclosure elements in the RSS feed, which is what makes it a podcast. I also point to the mp3 files from
audio elements on the individual episode pages—just above the transcript of each episode. Here’s the page for the most recent episode.
I also want people to be able to download the mp3 file directly if they want (or if they want to huffduff an episode). So I provide a link to the mp3 file with a good ol’-fashioned
a element with an
I throw in one more attribute on that link. The
download attribute tells the browser that the URL in the
href attribute should be downloaded instead of visited. If you give a value for the
download attribute, it will over-ride the file name:
<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>
Or you can use it as a Boolean attribute without any value if you’re happy with the file name:
<a href="/files/nice-file-name.xyz" download>download</a>
There’s one catch though. The
download attribute only works for files on the same origin. That’s an issue for me. My site is
podcast.clearleft.com but my audio files are hosted on
download attribute will be ignored and the mp3 files will play in the browser instead of downloading.
I added a file called
_redirects to the root of my project. It contains one line:
/download/* https://clearleft-audio.s3.amazonaws.com/podcast/:splat 200
That says that any URLs beginning with
/download/ should redirect to
clearleft-audio.s3.amazonaws.com/podcast/. Everything after the closing slash is captured with that wild card asterisk. That’s then passed along to the redirect URL as
:splat. That’s a new one on me. I hadn’t come across that terminology, but as someone who can never remember the syntax of regular expressions, it works for me.
Oh, and the
200at the end is the status code: okay.
Now I can use this
/download/ path in my link:
<a href="/download/season01episode06.mp3" download>Download mp3</a>
Because this URL on the same origin, the
download attribute works just fine.
Sunday, August 16th, 2020
Reading Agency by William Gibson.
!important in CSS are ways of solving your immediate problem …but unless you know what you’re doing, they’re probably going to create new problems.
A four-point checklist for inclusive design:
Are you a person that makes digital things for other people? Awesome—because this page is all about making things for people. There are four ways you can improve your creation for everybody. All four are testable, fixable and they improve usability for everybody.
Now this is the kind of response I was hoping to stir up with the first season of the Clearleft podcast!
With echos of design’s subjugation reverberating across all six episodes, this first season inadvertently told the story of how my profession has been captured by a desire to serve business interests above all others, while being disarmed by its tendency for introspection and need to be recognised.
Can digital design redeem itself? I hope so. Maybe in the next season of the Clearleft podcast, we’ll find out how.
What a brilliant homage! And what a spot-on pop-cultural reference for The Situation.
2020: an isolation odyssey is a reenactment of the iconic finale of 2001: A Space Odyssey (Stanley Kubrick, 1968). Restaged in the context of home quarantine, the journey through time adapts to the mundane dramas of self-isolation–poking fun at the navel-gazing saga of life alone and indoors.
Saturday, August 15th, 2020
I’ve recorded a tune a day for 150 days straight:
It’s too late to stop now.
Friday, August 14th, 2020
Matt made this website to explain RSS to people who are as-ye unfamilar with it.
As a web designer or developer burnout comes calling when you try to do good work, but you’re not allowed.
- You want to make the app more performant; your boss wants to fill it full of third party trackers
- You want to make the app more accessible; your boss wants you to focus on the ‘able market’ instead
- You want to word the app more clearly; your boss wants to trick users with misleading language
If you are a good developer, and a good person, asked to do shit work, you will burn out.
Thursday, August 13th, 2020
Season one of the Clearleft podcast
The Clearleft Podcast has finished its inaugural season.
I have to say, I’m pretty darned pleased with the results. It was equal parts fun and hard work.
Design Systems. This was a deliberately brief episode that just skims the surface of all that design systems have to offer. It is almost certainly a theme that I’ll revisit in a later episode, or even a whole season.
The main goal of this episode was to get some answers to the questions:
- What is a design system exactly? and
- What’s a design system good for?
I’m not sure if I got answers or just more questions, but that’s no bad thing.
Service Design. This is the classic topic for this season—an investigation into a phrase that you’ve almost certainly heard of, but might not understand completely. Or maybe that’s just me. In any case, I think that coming at this topic from a viewpoint of relative ignorance is quite a benefit: I have no fear of looking stupid for asking basic questions.
Wildlife Photographer Of The Year. A case study. This one was a lot of fun to put together.
Design Ops. Again, a classic example of me asking the dumb questions. What is this “design ops” thing I’ve heard of? Where’d it come from?
My favourite bit of feedback was “Thanks to the podcast, I now know what DesignOps is. I now also hate DesignOps”
I couldn’t resist upping the ante into a bit of a meta-discussion about whether we benefit or not from the introduction of new phrases like this into our work.
Design Maturity. This could’ve been quite a dry topic but I think that Aarron made it really engaging. Maybe the samples from Bladerunner and Thunderbirds helped too.
This episode finished with a call to action …with the wrong URL. Doh! It should’ve been surveymonkey.co.uk/r/designmaturity
Design Sprints. I like how the structure of this one turned out. I felt like we tackled quite a few angles in less than 25 minutes.
That’s a good one to wrap up this season, I reckon.
If you’re interested in the behind-the-scenes work that went into each episode, I’ve been blogging about each one:
- Design Systems
- Service Design
- Wildlife Photographer Of The Year
- Design Ops
- Design Maturity
- Design Sprints
I’m already excited about doing a second season …though I’m going to enjoy a little break from podcasting for a little bit.
As I say at the end of most episodes, if you’ve got any feedback to offer on the podcast, send me an email at firstname.lastname@example.org
And if you’ve enjoyed the Clearleft podcast—or a particular episode—please share it far and wide.