A stream of consciousness by Laurence Hughes

I’ve written before that CSS transition is great for simple animations triggered by an event. You might want to transition something in response to a focus or hover event. Or, perhaps your use case is that the user activates a button to launch a previously-hidden dialog element and you want to use transition to animate the dialogue’s entrance and exit.

Recently I updated this website’s git repository README to include a summary of my approach to supporting post excerpts.

I define an initial part of a post as the excerpt by adding a separator string between it and the remaining content. Then in my posts list I grab 11ty’s post.page.excerpt and pass that through a custom markdown-parsing filter.

This works pretty well but sometimes it’s a bit inflexible that the excerpt has to be part of the post. Sometimes you might want to say something different, or shorter and snappier in the excerpt.

I’m partial to going down the rabbit-hole on a niche aspect of front-end development. For example a few years ago I got the urge to dig into what’s going on with containers and items in Flexbox-powered layouts and noted my findings in Flexbox-fu. I do it to go beyond the thing’s theory and into its practical application for solving real web development challenges; to gain a deeper understanding of why things behave the way they do. These deep dives take time but are rewarding; usually I’ll learn about more than I expected.

Recently I dug into the characteristics and behaviour of the CSS outline property. The catalyst was seeing Heydon Pickering’s clever use of outline to automate divider lines within a flexbox powered navigation menu. I couldn’t fathom how it works so decided to reverse-engineer it. More on Heydon’s trick later, but I’ll start with a recap of what outline is good for.

A thought-provoking look at how LLMs might lower the burden of writing useful alt text for images, and – given the right prompts – produce better results than humans doing it manually.

It’s far more descriptive than what I would have written without it.

Jared goes on to argue that the benefits really multiply when working at scale. This part made me think of the content team at my work who maintain a customer-facing knowledge base and need to write alt text for hundreds of screenshots.

A huge time-saver is if you’re working with a large set of images. You can write the prompt only once and then say you want the same applied to each image you upload.

Hidde is, like me, both an “accessibility nerd” and “a components enthusiast”. So it’s interesting to see him tackle whether it’s sensible for design systems – even really good ones – to “promise accessibility”.

We should definitely test how accessible components are and document what they can and can't contribute to a website's accessibility. And WCAG requirements can help with this. However, I think claiming WCAG conformance about pages or sets of pages, as we do today, approaches it at the right level. I don't think we should want to claim conformity of components by themselves.

He goes on to say:

There's a real risk in overpromising the value of a component if we say it is accessible or conforms to some accessible standard. It could make people believe that they no longer need to worry about accessibility once they use or buy the component. That creates the wrong expectations: accessibility is a continuous process. Like we want to always iterate on user experience, we want to always iterate on accessibility.

Here are my main takeaways.