A short text file, imbued with meaning and memory.
Monday, January 7th, 2019
Dave on the opaqueness of toolchains:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.
There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:
In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.
I really like this suggestion for making the invisble visible:
I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.
Back in 1993, David Raggett wrote up all the proposed extensions to HTML that were being discussed on the www-talk mailing list. It was called HTML+, which would’ve been a great way of describing HTML5.
Twenty five years later, I wish that the proposed
IMAGE element had come to pass. Unlike the
IMG element, it would’ve had a closing tag, allowing for fallback content between the tags:
The IMAGE element behaves in the same way as IMG but allows you to include descriptive text, which can be shown on text-only displays.
Yeah, I know we have the
alt attribute, but that’s always felt like an inelegant bolt-on to me.
An interesting proposal from Jake on a different way of defining how service worker fetch events could be handled under various conditions. For now, I have no particular opinion on it. I’m going to let this stew in my mind for a while.
Sunday, January 6th, 2019
Thursday, January 3rd, 2019
The first two years of the excellent History Of The Web newsletter is now available as a digital book. It’s volume one of …we’ll see how many.
Buried inside you’ll find fascinating narrative threads from the web’s history, starting all the way from the beginning and straight on through to the very first browsers, the emergence of web design, to the evolving landscape of our online world.
This is a recording of my Evaluating Technology talk from An Event Apart in Denver just over a year ago. This was the last time I ever gave this talk, and I think you can tell that the delivery is well-practiced; I’m very happy with how this turned out.
In this 60-minute presentation recorded live at An Event Apart Denver 2017, Jeremy Keith helps you learn to evaluate tools and technologies in a way that best benefits the people who use the websites you design and develop.
An ode for every element in the periodic table, in the form of a haiku.
Well, this could be very handy for Huffduffer!
Wednesday, January 2nd, 2019
April 7th, 2019 is going to be the 50 year anniversary of the first ever Request for Comments, known as an RFC.
Darius Kazemi is going to spend the year writing commentary on the first 365 Request For Comments from the Internt Engineering Task Force:
In honor of this anniversary, I figured I would read one RFC each day of 2019, starting with RFC 1 and ending with RFC 365. I’ll offer brief commentary on each RFC.
Tuesday, January 1st, 2019
A profile of Brighton, featuring Clearleft’s own Chris How.
These are good challenges to think about. Almost all of them are user-focused, and there’s a refreshing focus away from reaching for a library:
It’s tempting to read about these problems with a particular view library or a data fetching library in mind as a solution. But I encourage you to pretend that these libraries don’t exist, and read again from that perspective. How would you approach solving these issues?
Monday, December 31st, 2018
I can relate to Ethan’s 16-step process for writing conference talks.
Step 14 is the most important.
Sunday, December 30th, 2018
I love this use of e-ink to play a film at 24 frames per day instead of 24 frames per minute.
Saturday, December 29th, 2018
The secret is: if you use semantic HTML, then they do the work, not you. Their browser does the work, not you. If your pages use semantic HTML, you’re not going to get bug reports saying that your web app doesn’t work in a screenreader, or your buttons don’t work without mouse clicks, or your site doesn’t show anything on a Yoyodyne SuperPhone 3 running FailBrowser, because it will and they will and it will. And using semantic HTML elements is no more effort; it’s just as easy to use
mainas it is to use
div id="main". Easier, even.
Another good reason to use the
currentColor value in SVGs.
I reckon it’s time for distressed type to make a comeback—CSS is ready for it.