Links

Today I learned about the CSS property text-underline-position. As Stuart mentions, the under value forces the underline to sit below all the descenders, giving you a consistent baseline.

a {
	text-underline-position: under;
}

• Good software depends on judgment, communication, and clear abstraction. AI has amplified this.
• AI coding is automation of implementation, so design and stewardship become more important.

Zach Leatherman on frontend architecture and building for longevity amid framework churn:

1. 👏 Hire someone that’s good at HTML and CSS to build components independent of JS frameworks 👏
2. Plug components into a JS framework and layer on behavior later
3. Pay HTML/CSS devs what they deserve for giving part of your codebase longer shelf life than unpasteurized milk

It’s never been a good idea to ship everything you think of. Every addition accretes complexity and comes with a cognitive cost.

Maybe we need to reframe the concept of scarcity from us, the makers of software, to them, the users of software. Their resources are what matter most:

• Attention (too many features and they can’t all be used, or even tried)
• Stability (too much frequent change is an impediment to learning a product)
• Clarity (too many options creates confusion and paralysis)
• Coherence (too many plots and subplots cannot tell a unified story)

Similarly we all love when the swifts visit (beautiful birds), so somebody started a group to get swift nest boxes made and installed collectively, then applied for subsidy funding, then got everyone to chip in such that people who couldn’t afford it could have their boxes paid for, and now suddenly we’re all writing to MPs and following the legislation to include swift nesting sites in new build houses. Etc.

It’s called collective efficacy, the belief that you can make a difference by acting together.

Every time you are inclined to use the word “teach”, replace it with “learn”. That is, instead of saying, “I teach”, say “They learn”. It’s very easy to determine what you teach; you can just fill slides with text and claim to have taught. Shift your focus to determining how you know whether they learned what you claim to have taught (or indeed anything at all!). That is much harder, but that is also the real objective of any educator.

The problem is that Live Text, “Select text in images to copy or take action,” is enabled by default on iOS devices (Settings → General → Language & Region), which can interfere with the contextual menu in Safari. Pressing down on the above link may select the text inside the image instead of selecting the link URL.

Excellent framing from Jim Nielsen, building on Jake Nations’ talk about shipping code we don’t fully understand.

Easy means you can do with little effort.

Simple means you can understand what you do with little effort.

In this excellent, data-driven talk, Alex Russell explains:

• What “winning” means for the web and why it’s a vital cause
• How the web is losing the competition today on mobile, despite its success on desktop
• The path forward: Getting things out of frameworks and using the web platform

Jeremy Wagner and Rachel Andrew explain how to use analytics to select a Baseline target and what to do when you don’t have any real user data.

In cases where there isn’t any real user data:

[…] you can get a general idea of support for different Baseline targets through RUM Archive Insights, even allowing you to filter down to the country level.

They also address a practical follow-up question: what to do about features that don’t meet your chosen Baseline target.

Baseline doesn’t prescribe a specific path here, but the authors suggest a useful framework for categorizing features based on their “failure mode”:

• Enhancement: If the feature is used in an unsupported browser, the experience is not broken. The experience could possibly be degraded, but may not likely be noticeable to the user. Example: loading="lazy".
• Additive: The feature provides some additive benefits that may be noticeable—such as changes in page styling or some functionality. The difference may not be noticeable to users if the feature is unsupported, barring comparison in a browser that does support it. Example: Subgrid
• Critical: If the feature is unsupported, the user will have a negative user experience—possibly even one that’s broken altogether. Example: File System Access API used as a central and necessary feature.

They also highlight Clearleft’s browser support policy, where they target Baseline Widely available while still evaluating whether newer features can be used as progressive enhancements before ruling them out entirely.

I just saw Jason Pamental’s excellent talk on ‘The Life of <p>’. In this talk, Jason traces the evolution of paragraph design in print and shows how those typographic ideas can be applied using CSS.

There’s one moment during the Q&A where Jason mentions:

[…] you see the page gets small, but they don’t change the scale of the headers. So you end up with like an <h1> with one word per line. It’s a really awkward break. So I think proportion with varying screen size is probably the most overlooked thing right now that I’d want to see people think about more.

I wasn’t a web developer 10 years ago when Jason gave this talk, but with over five years of experience now, it’s striking that I only became aware of proportional type scaling as an idea in the last couple of years. Nowadays, I use utopia.fyi to create fluid type (and space) scales across viewport ranges, which helps address the problem Jason mentioned.

Underlying our browser support policy are two foundational principles:

1. Website content and core functionality should be accessible to everyone.
2. It’s okay for websites to look different in different browsers.

If content is unreadable in some browsers, that’s a bug that we will fix.

If content is displayed slightly differently in some browsers, we consider that to be a facet of the web, not a bug. This means that there will sometimes be subtle visual and functional differences from browser to browser. We deem this acceptable provided content and core functionality are unaffected.

Great talk by Andy Allen on how software designers can learn from game designers.

It reminded me of the Wheel by Adam Argyle, inspired by the arcade game Black Emperor. The game feel is so strong that I find myself scrolling up and down again and again just to play with it and experience that delightful bounce effect.

Jason Lengstorf on how to get hired as a developer:

• Document what you learn publicly — consistency matters more than polish.
• Show your work — CodePen demos, personal projects or tutorials all count.
• Participate in communities — Bluesky, Mastodon, Discord.

Instead of seeing us as people who brought valuable knowledge and expertise to the project, they saw us as the hands that would execute their vision.

The above bit from Nic captures a dynamic I want to address upfront with clients, so they never treat me as just a pair of hands.

Then there’s the this bit, which really resonated with me (because I’ve been there too and it sucks):

While I personally believe in the value of good design, I also believe there are a lot of smoke-and-mirrors in the industry, and I hated the thought that I might have inadvertently contributed to it. Even if the client is happy, it didn’t meet my internal bar for a quality product worth sticking my name on, and I feel like I’ve let down both the client and the end-users.

Nic mentions how they hope to avoid similar situations in the future by blogging:

By blogging, I’m putting a body of work out there that communicates my values and ethos. While much of the details of my client work has to remain private, these posts can be public, and hopefully they can help me find people who resonate with what I have to offer. Or you know, just be bold enough to communicate ‘Fuck off’ to those who don’t!

Roman Komarov on how they use an IIFE (Immediately Invoked Function Expression) to handle complex conditional rendering in .astro components.

---
const { linkText, isDiv = false } = Astro.props;
---

{
	(() => {
		const someContent = <a href="#hello">{linkText}</a>;
		return (
			<div class="wrapper">
				{isDiv ? (
					<div class="inner">{someContent}</div>
				) : (
					<span class="inner">{someContent}</span>
				)}
			</div>
		);
	})()
}

Loved this bit from Rahul Desai’s review of ‘Dhurandhar’:

[…] the term “fictional film inspired by real events” means that historical authenticity will be cited if the film-making is questioned, and fiction will be cited if the historical authenticity is questioned.

Mandy Michael uses a brilliant analogy to explain why developers must get to know the HTML elements available to them and use the appropriate one for their content.

In TypeScript, we have the concept of an any type. When you assign a type of any it means the content can be anything. […] But if everything is typed as any then you lose the benefits of the language.

This is the same with HTML. If you use the <div> everywhere, you aren’t making the most of language. Because of this it’s important that you actively choose what the right element is and don’t just use the default <div>.

This reminded me of the following quote by Jen Simmons from their HTML course:

HTML syntax itself is fairly simple. The trickier part is knowing which tags to use when.

Images on the web are hard. After trying and failing so many times before, now I finally understand how to configure srcset and sizes attributes to serve differently sized images for different viewports.

Also worth checking out: Image Display Elements by Stephanie Eckles.

@ts-expect-error will let you know when there’s no TypeScript error to silence and when it has become useless. @ts-ignore will stay put and sit silently wherever you placed it.

Not only did I not know the difference between @ts-ignore and @ts-expect-error, I was totally unaware there was such a directive as @ts-expect-error.