Wednesday, November 25th, 2020
Sunday, November 22nd, 2020
Cassie’s enthusiasm for fun and interesting SVG animation shines through in her writing!
Saturday, November 14th, 2020
I like the way that Simon is liberating his data from silos and making it work for him.
Friday, November 13th, 2020
Thursday, November 12th, 2020
Thursday, November 5th, 2020
Saturday, October 31st, 2020
Monday, October 19th, 2020
Continuous partial browser support
That’s not what happened though. Developers used vendor-prefixed properties as though they were stable. Tutorials were published that basically said “Go ahead and use these vendor-prefixed properties and ship it!” There were even tools that would add the prefixes for you so you didn’t have to type them out for yourself.
Browsers weren’t completely blameless either. Long after features were standardised, they would only be supported in their prefixed form. Apple was and is the worst for this. To this day, if you want to use the
clip-path property in your CSS, you’ll need to duplicate your declaration with
-webkit-clip-path if you want to support Safari. It’s been like that for seven years and counting.
Like capitalism, vendor prefixes were one of those ideas that sounded great in theory but ended up being unworkable in practice.
Still, developers need some way to get their hands on experiment features. But we don’t want browsers to ship experimental features without some kind of safety mechanism.
- Developers are able to register for an experimental feature to be enabled on their origin for a fixed period of time measured in months. In exchange, they provide us their email address and agree to give feedback once the experiment ends.
- Usage of these experiments is constrained to remain below Chrome’s deprecation threshold (< 0.5% of all Chrome page loads) by a system which automatically disables the experiment on all origins if this threshold is exceeded.
I think it works pretty well. If you’re really interested in kicking the tyres on an experimental feature, you can opt in to the origin trial. But it’s very clear that you wouldn’t want to ship it to production.
You could ship something that’s behind an origin trial, but you’d have to make sure you’re putting safeguards in place. At the very least, you’d need to do feature detection. You certainly couldn’t use an experimental feature for anything mission critical …but you could use it as an enhancement.
And that is a pretty great way to think about all web features, experimental or otherwise. Don’t assume the feature will be supported. Use feature detection (or
@supports in the case of CSS). Try to use the feature as an enhancement rather than a dependency.
If you treat all browser features as though they’re behind an origin trial, then suddenly the landscape of browser support becomes more navigable. Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”
You can also do it for well-established features like
geolocation. Instead of assuming that browser support is universal, it doesn’t hurt to take a more defensive approach. Assume nothing. Acknowledge and embrace unpredictability.
The debacle with vendor prefixes shows what happens if we treat experimental features as though they’re stable. So let’s flip that around. Let’s treat stable features as though they’re experimental. If you cultivate that mindset, your websites will be more robust and resilient.
More on battling entropy:
Ever needed to change “just a small thing” on an old page you build years ago? I recently had the pleasure and the simple task of changing some colors in CSS lead to a whole day of me wrangling with old deprecated Grunt tasks and trying to get the build task running.
I like this mindset:
Be boring by default and enhance on the way.
I like this idea for a minimum viable note-taking app:
data:text/html,<body contenteditable style="line-height:1.5;font-size:20px;">
I have added this to bookmarks and now my zero-weight text editor is one keypress away from me. You might also use it as a temporary clipboard to paste text or even pictures.
See also: a minimum viable code editor.
Sunday, October 18th, 2020
A timeline showing the history of non-digital dataviz.
Tuesday, October 13th, 2020
My name is Jeremy Keith and I endorse this message:
I love the modern JS platform (the stuff the browser does for you), and hate modern JS tooling.
Five pieces of low-hanging fruit:
- Unlabelled links and buttons
- No image descriptions
- Poor use of headings
- Inaccessible web forms
- Auto-playing audio and video
Monday, October 12th, 2020
The Web History podcast
Recently Jay started publishing essays on web history over on CSS Tricks:
Round about that time, Chris floated the idea of having people record themselves reading blog posts. I immediately volunteered my services for the web history essays.
So now you can listen to me reading Jay’s words:
Each chapter is round about half an hour long so that’s a solid two hours or so of me yapping.
And if you just can’t get enough of my voice, there’s always the Clearleft podcast …although that’s mostly other people talking, thank goodness.
This post really highlights one of the biggest issues with the convoluted build tools used for “modern” web development. If you return to a project after any length of time, this is what awaits:
I find entropy staring me back in the face: library updates, breaking API changes, refactored mental models, and possible downright obsolescence. An incredible amount of effort will be required to make a simple change, test it, and get it live.
Take a moment and think about this super power: if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs. Edit a file, refresh the page, you’ve got a feedback cycle. As soon as you introduce tooling, as soon as you introduce an abstraction not native to the browser, you may have to invent the universe for a feedback cycle.
Maintainability matters—if not for you, then for future you.
The more I author code as it will be run by the browser the easier it will be to maintain that code over time, despite its perceived inferior developer ergonomics (remember, developer experience encompasses both the present and the future, i.e. “how simple are the ergonomics to build this now and maintain it into the future?) I don’t mind typing some extra characters now if it means I don’t have to learn/relearn, setup, configure, integrate, update, maintain, and inevitably troubleshoot a build tool or framework later.
Thursday, October 8th, 2020
A follow-up to full-bleed layout post I linked to recently. Here’s how you can get the same effect with using CSS grid.
I like the use of the principle of least power not just in the choice of languages, but within the application of a language.
Tuesday, October 6th, 2020
Match up images that have been posted in pairs to Twitter with the caption “same energy”. This is more fun and addictive than it has any right to be.
Monday, October 5th, 2020
When you’ve got a single centered column but you want something (like an image) to break out and span the full width.