Wednesday, August 19th, 2020
Tuesday, August 18th, 2020
Examples of defensive coding for CSS. This is an excellent mindset to cultivate!
Monday, August 17th, 2020
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
!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.
Friday, August 14th, 2020
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.
Monday, August 10th, 2020
Hidde gave a great talk recently called On the origin of cascades (by means of natural selectors):
It’s been 25 years since the first people proposed a language to style the web. Since the late nineties, CSS lived through years of platform evolution.
It’s a lovely history lesson that reminded me of that great post by Zach Bloom a while back called The Languages Which Almost Became CSS.
The TL;DR timeline of CSS goes something like this:
- June 1993: Rob Raisch proposes some ideas for stylesheets in HTML on the
- October 1993: Pei Wei shares his ideas for a stylesheet language, also on the
- October 1994: Håkon Wium Lie publishes Cascading HTML style sheets — a proposal.
- March 1995: Bert Bos publishes his Stream-based Style sheet Proposal.
Håkon and Bert joined forces and that’s what led to the Cascading Style Sheet language we use today.
Hidde looks at how the concept of the cascade evolved from those early days. But there’s another idea in Håkon’s proposal that fascinates me:
While the author (or publisher) often wants to give the documents a distinct look and feel, the user will set preferences to make all documents appear more similar. Designing a style sheet notation that fill both groups’ needs is a challenge.
The proposed solution is referred to as “influence”.
The user supplies the initial sheet which may request total control of the presentation, but — more likely — hands most of the influence over to the style sheets referenced in the incoming document.
So an author could try demanding that their lovely styles are to be implemented without question by specifying an influence of 100%. The proposed syntax looked like this:
h1.font.size = 24pt 100%
More reasonably, the author could specify, say, 40% influence:
h2.font.size = 20pt 40%
Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.
Okay, that sounds pretty convoluted but then again, so is specificity.
This idea of influence in CSS reminds me of Cap’s post about The Sliding Scale of Giving a Fuck:
Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel?
I’m probably a six-out-of-ten, I replied after a couple moments of consideration.
Cool, then let’s do it your way.
In the end, the concept of influence in CSS died out, but user style sheets survived …for a while. Now they too are as dead as a dodo. Most people today aren’t aware that browsers used to provide a mechanism for applying your own visual preferences for browsing the web (kind of like Neopets or MySpace but for literally every single web page …just think of how empowering that was!).
Even if you don’t mourn the death of user style sheets—you can dismiss them as a power-user feature—I think it’s such a shame that the concept of shared influence has fallen by the wayside. Web design today is dictatorial. Designers and developers issue their ultimata in the form of CSS, even though technically every line of CSS you write is a suggestion to a web browser—not a demand.
I wish that web design were more of a two-way street, more of a conversation between designer and end user.
There are occassional glimpses of this mindset. Like I said when I added a dark mode to my website:
Y’know, when I first heard about Apple adding dark mode to their OS—and also to CSS—I thought, “Oh, great, Apple are making shit up again!” But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don’t get the last word—users do.
Wednesday, August 5th, 2020
A great little history lesson from Amber—ah, Firebug!
Saturday, August 1st, 2020
So, why would you want to use a service worker? Here are some cool things you can do with it.
Chris lists some of the ways a service worker can enhance user experience.
Friday, July 31st, 2020
Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web? — Smashing Magazine
I really enjoyed this interview between Drew and Chris. I love that there’s a transcript so you can read the whole thing if you don’t feel like huffduffing it.
Recreating Wildlife Photographer of the Year online – part 1 – Introduction and technical approach – Blogs from the Natural History Museum
Now here’s the story from the team that made the website. It’s a great walkthrough of thoughtfully evaluating technologies to figure out the best approach.
This is a great talk by Hidde, looking at the history and evolution of cascading style sheets. Right up my alley!
Thursday, July 30th, 2020
What web development can learn from the Nintendo Game and Watch.
The Web now consists of an ever-growing number of different frameworks, methodologies, screen sizes, devices, browsers, and connection speeds. “Lateral thinking with withered technology” – progressively enhanced – might actually be an ideal philosophy for building accessible, performant, resilient, and original experiences for a wide audience of users on the Web.
Friday, July 24th, 2020
This is such a clever and useful technique! It’s HTML+CSS only, and it’s a far less annoying way to display animated GIFs.
(Does anybody even qualify the word GIF with the adjective “animated” anymore? Does anyone know that there used to be such a thing as non-animated GIFs and that they were everywhere?)
A heartfelt look at progressive enhancement:
Some look at progressive enhancement like a thing from the past of which the old guard just can’t let go. But to me, progressive enhancement is the future of the Web. It is the basis for building resilient, performant, interoperable, secure, usable, accessible, and thus inclusive experiences. Not only for the Web of today but for the ever-growing complexity of an ever-changing and ever-evolving Web.
This is great! Ideas for allowing more styling of form controls. I agree with the goals 100% and I like the look of the proposed solutions too.
The team behind this are looking for feedback so be sure to share your thoughts (I’ll probably formulate mine into a blog post).
This is a great bit of detective work by Amber! It’s the puzzling case of The Browser Dev Tools and the Missing Computed Values from Custom Properties.
Who do I know working on dev tools for Chrome, Firefox, or Safari that can help Amber find an answer to this mystery?
Thursday, July 23rd, 2020
This is a nifty visual interactive explainer for the language of CSS—could be very handy for Codebar students.
Saturday, July 18th, 2020
These wonderfully realistic photo effects from Lynn are quite lovely!