I’m very taken with Github’s tab-container element—this is exactly how I think web components should be designed!
Sunday, March 7th, 2021
Saturday, January 16th, 2021
Remember when I wrote about Web Audio weirdness on iOS? Well, this is a nice little library that wraps up the same hacky solution that I ended up using.
It’s always gratifying when something you do—especially something that feels so hacky—turns out to be independently invented elsewhere.
Friday, December 18th, 2020
I wish more companies would realise that this is a perfectly reasonable approach to take:
We decided to look for a solution. After a brief search, we found one: just don’t use any non-essential cookies. Pretty simple, really. 🤔
So, we have removed all non-essential cookies from GitHub, and visiting our website does not send any information to third-party analytics services.
Monday, February 24th, 2020
Jen kicked off a fascinating thread here:
It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.
The level is discourse is impressively smart and civil.
Personally, I don’t (yet) have an opinion on this either way, but I’ll be watching it unfold with keen interest.
Thursday, January 9th, 2020
This is a great proposal that would make the Cache API even more powerful by adding metadata to cached items, like when it was cached, how big it is, and how many times it’s been retrieved.
Tuesday, November 19th, 2019
The GitHub Archive Program will safely store every public GitHub repo for 1,000 years in the Arctic World Archive in Svalbard, Norway.
This is a fascinating project from Github, the Long Now Foundation, the Internet Archive, the Bodleian Library and others. All of the public code on Github on February 2nd, 2020 will be archived for 1000 years in a vault in Svalbard.
Mind you, given the amount of dependencies that most “modern” code projects rely on, I can’t foresee the code working after 1000 days.
Saturday, August 24th, 2019
I would very much like this to become a reality.
Never-Slow Mode (“NSM”) is a mode that sites can opt-into via HTTP header. For these sites, the browser imposes per-interaction resource limits, giving users a better user experience, potentially at the cost of extra developer work. We believe users are happier and more engaged on fast sites, and NSM attempts to make it easier for sites to guarantee speed to users. In addition to user experience benefits, sites might want to opt in because browsers could providing UI to users to indicate they are in “fast mode” (a TLS lock icon but for speed).
Thursday, August 22nd, 2019
Keep what you need, delete what you don’t and add whatever you like on top of whats already there.
Friday, June 7th, 2019
Saturday, February 23rd, 2019
Saturday, February 9th, 2019
This is a really interesting approach that isn’t quite a CSS reset or a normalisation. Instead, it’s an experiment to reimagine what a default browser stylesheet would be like if it were created today, without concerns about backwards compatibility:
Applies basic styling to form elements and controls, getting you started with custom styling. We want to find the balance between providing a base for implementing a custom design, and allowing OS-level control over how form inputs work (like how a number pad works on iOS).
Provides a very lightweight starter file, with generic visual styling that you will want to replace. This isn’t as robust or opinionated as a starter-theme or framework. We’ve leaned toward specifying less, so you have less to override. (We haven’t defined any font families, for example.)
You can contribute by adding issues.
Saturday, November 17th, 2018
Tuesday, November 13th, 2018
Remember when I said that if we want to see CSS exclusions implemented in browsers, we need to make some noise?
Well, Rachel is taking names, so if you’ve got a use-case, let her know.
Sunday, September 9th, 2018
You really don’t need jQuery any more …and that’s thanks to jQuery.
Tuesday, July 10th, 2018
Paul Ford explains version control in a way that is clear and straightforward, while also being wistful and poetic.
I had idle fantasies about what the world of technology would look like if, instead of files, we were all sharing repositories and managing our lives in git: book projects, code projects, side projects, article drafts, everything. It’s just so damned … safe. I come home, work on something, push the changes back to the master repository, and download it when I get to work. If I needed to collaborate with other people, nothing would need to change. I’d just give them access to my repositories (repos, for short). I imagined myself handing git repos to my kids. “These are yours now. Iteratively add features to them, as I taught you.”
Saturday, May 12th, 2018
A good core experience is indicative of a well-structured web page, which, in turn, is usually a good sign for SEO and for accessibility. It’s usually a well designed web page, as the designer and developer have spent time and effort thinking about what’s truly core to the experience. Progressive enhancement means more robust experiences, with fewer bugs in production and fewer individual browser quirks, because we’re letting the platform do the job rather than trying to write it all from scratch.
Saturday, April 28th, 2018
If you’re looking for an accessible standalone autocomplete script, this one from GDS looks very good (similar to Lea’s awesomplete).
A plugin for Slack that will make it look like you’re typing whenever someone else is typing. It isn’t annoying at all.
Friday, March 2nd, 2018
Just change it
Amber and I often have meta conversations about the nature of learning and teaching. We swap books and share ideas and experiences whenever we’re trying to learn something or trying to teach something. A topic that comes up again and again is the idea of “the curse of knowledge“—it’s the focus of Steven Pinker’s book The Sense Of Style. That’s when the author/teacher can’t remember what it’s like not to know something, which makes for a frustrating reading/learning experience.
This is one of the reasons why I encourage people to blog about stuff as they’re learning it; not when they’ve internalised it. The perspective that comes with being in the moment of figuring something out is invaluable to others. I honestly think that most explanatory books shouldn’t be written by experts—the “curse of knowledge” can become almost insurmountable.
I often think about this when I’m reading through the installation instructions for frameworks, libraries, and other web technologies. I find myself put off by documentation that assumes I’ve got a certain level of pre-existing knowledge. But now instead of letting it get me down, I use it as an opportunity to try and bridge that gap.
The brilliant Safia Abdalla wrote a post a while back called How do I get started contributing to open source?. I definitely don’t have the programming chops to contribute much to a codebase, but I thoroughly agree with Safia’s observation:
If you’re interested in contributing to open source to improve your communication and empathy skills, you’re definitely making the right call. A lot of open source tools could definitely benefit from improvements in the documentation, accessibility, and evangelism departments.
What really jumps out at me is when instructions use words like “simply” or “just”. I’m with Brad:
“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources. “Just” is a dangerous word.
But rather than letting that feeling overwhelm me, I now try to fix the text. Here are a few examples of changes I’ve suggested, usually via pull requests on Github repos:
- The instructions on the AMP validator page.
- The documentation for Composer, the PHP dependency manager.
They all have different codebases in different programming languages, but they’re all intended for humans, so having clear and kind documentation is a shared goal.
I like suggesting these kinds of changes. That initial feeling of frustration I get from reading the documentation gets turned into a warm fuzzy feeling from lending a helping hand.
Thursday, March 1st, 2018
A look at the font stack that Github is using.