CSS and design systems people - BlogFlock

Let the stagger experiments begin - Adam Argyle

2025-03-11T00:08:03.000Z

li { --stagger: calc((sibling-index() - 1) * .1s); transition: opacity 1s var(--ease-3) var(--stagger), translate 1s var(--ease-spring-3) var(--stagger); } " height="758" width="1272" />

2019, I proposed an idea to help remove a ton of boilerplate code from CSS and HTML while also making stagger effects easier on authors. The proposal ended up being sibling-index() and sibling-count().

Fun news! You can try it in Canary today and I've got this little example to help kick off some ideas for you!

Try on Codepen

Staggering animation #

Instead of inlining a CSS variable for each element:

<div class="parent" style="--sibling-count: 5">
  <div style="--sibling-index: 1"></div>
  <div style="--sibling-index: 2"></div>
  <div style="--sibling-index: 3"></div>
  <div style="--sibling-index: 4"></div>
  <div style="--sibling-index: 5"></div>
</div>

You can use sibling-index() to retrieve it just in time instead of doing the work in the template or JS.

Clean that HTML up to make room for sibling-index() by removing all the inline styles:

<div class="parent">
  <div></div>
  <div></div>
  <div></div>
  <div></div>
  <div></div>
</div>

and then drop in this new magic bomb:

.parent > * {
  transition: opacity 0.3s ease;
  transition-delay: calc(sibling-index() * 100ms);
}

and now you have a 100ms staggered crossfade transition effect 🤓

Staggering color #

There's nothing stopping you from using sibling-index() to stagger a color change, or anything else!

Here the hue increments by 50 each element.

.parent > * {
  --hue: calc(sibling-index() * 50);
  color: oklch(70% 70% var(--hue));
}

You could easily add a min() or clamp() or trig functions to help you too.

Time to experiment #

Share with me what you build! Fork this Codepen

Abandon all keyboards - Robin Rendle

2025-03-11T00:02:06.000Z

It’s obnoxiously beautiful right now.

It’s a cracking, 10/10 stunner of a California sunset and it’s pouring in through the windows of this empty cafe as I click-clack on my infinite click-clack machine. It’s as if the whole world has become a kaleidoscope of West Coast reds and oranges just for me. But, alas, I don’t feel much of anything. I am, in fact, this: a total and absolute nothing inside. Familiar feelings of course, nothing scary at all, it’s just plain ol’ burnout. There was a rush of work over a few months—go, go, go! build, build, build!—and then: something clicked and I was done. No more gas in the tank. No vacancies at the inn. All spoons gone.

The problem with these feelings is that they come out of nowhere and I ignore the symptoms until they bleed into other parts of my life. But if I can’t care for writing or reading or code or design or anything fun and exciting then what even am I? Enthusiasm is my middle name! I was born to point at things excitedly! And yet in the evenings now I’ll watch a great movie or a TV show or play a game where ten thousand people poured years of their lives into it and — nothing.

It all just kinda washes over me.

When this sort of thing happens I know what I need: abandon all keyboards! Discard all screens! Throw myself into a stack of books and hurl my charmless corpse across a foreign city so that my empathy and hope refills itself. But right now it’s tough to be optimistic about that because today nothing matters. Work? Eh. Friends? Bleurgh. Going outside? Taking care of myself? Planning things? Bleurgh.

Bleurgh to all things!

In moments like this there’s a shift in me towards mean and unpleasant thoughts, a kind of cynicism that’s impossible to shake. I see the worst in people, almost as if I’m hoping for the worst things to happen. But that cruelty tends to become laser-focused on me. Like the other day, when I woke up and my very first thought to start the day was: “christ, I’m such a bad designer.”

Yikes! What the hell, brain! Also: please pick something more cool and interesting to be sad about at the very least! I get that deep down you crave being interesting and sad but this is the least interesting way to sad! Try harder!

Anyway, I’ve booked two weeks off work. I’ll plan something, go somewhere, write something. I’ll figure it out.

But, until then: bleurgh.

Views on views - Hidde's blog

2025-02-28T16:13:12.240Z

If WCAG 3 would adopt the word “view” instead of “web page”, the standard would be more useful in non-web contexts like native apps, documents and XR. Because many wish to understand how accessible such environments are, we should consider adopting a unit that isn’t “web page”. To me, “view” is the strongest contender.

Context: as part of the Accessibility Guidelines Working Group (AGWG) work on WCAG 3, I'm leading a subgroup on (re)defining “views” for WCAG 3. This group builds further on a discussion at TPAC 2024, which builds on discussions over many years about WCAG and WCAG2ICT. Opinions in this post do not reflect those of the subgroup, or of my clients.

I would love any feedback in wcag3/discussions/286.

The web page

In WCAG, and most WCAG-related documents, the notion of a “web page” does quite a lot of work: it's in the name of some success criteria and it's WCAG 2's “unit of conformance”, i.e. the thing people can claim conformance about.

A web page, in WCAG 2, is unambiguously scoped to something to obtain from a single URI:

a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

It's so unambiguous that we'd struggle to come up with examples where one person would draw the boundary between two web pages differently than the next. Well done, team WCAG!

Inevitably, though, a unit of conformance that can apply more broadly will be more ambiguous.

In other places

No less than 16 success criteria in WCAG 2.2 mention web pages: 1.4.2 Audio control, 2.1.2 No keyboard trap, 2.3.1 Three flashes or below treshold, 2.3.2 Three flashes, 2.4.1 Bypass blocks, 2.4.2 Page titled, 2.4.3 Focus order, 2.4.5 Multiple ways, 2.4.8 Location, 2.5.6 Concurrent input mechanisms, 3.1.1 Language of page, 3.2.3 Consistent navigation, 3.2.4 Consistent identification, 3.2.6 Consistent help, 3.3.4 Error prevention (legal, financial data) and 3.3.6 Error prevention (all).

It's also used in documents like WCAG-EM, the evaluation method.

Conformance

“Web page” is WCAG 2's “unit of conformance”, meaning that if you want to say something “conforms” to WCAG, that something should be a web page, and not something else, like a date picker component that you've built. You can use WCAG to reason about the accessibility of that date picker component, but a claim that it conforms to WCAG would not make sense.

Note, the phrase “unit of conformance” isn't actually mentioned or defined in WCAG itself, but WCAG2ICT explains it clearly:

(…) the unit of conformance in WCAG 2 is a single web page (…)

(From Interpretation of Web Terminology in a Non-web Context)

Conformance claims are also specifically about full web pages, not parts of them. They can be about more than a single page, though:

a conformance claim may be made to cover one page, a series of pages, or multiple related web pages.

(From: WCAG 2.2, section 5.3: conformance claims)

That's common too: in fact, accessibility conformance reports usually cover a whole website.

Views

“Views” could be a new unit to use, meaning web pages on websites and other things in non-web contexts. View are not defined in WCAG 2 (they are in UAAG and in ATAG, interestingly, and a 1999 doc defines “page view”). The latest WCAG 3 draft also has a definition for view, we'll get to that later.

Views as a unit of conformance for WCAG have been considered before, most nobably in the WCAG2ICT groups, see for instance the discussion in reply to the concept of User Interface Context. In all those years, the group could not think of a definition that wouldn’t introduce problems of its own.

Has anything really changed since then? Well, one thing that is different now, is that we have more variety in products that need accessibility conformance evaluated than ever. There seems to be a growing desire to bring our units of conformance up to date with that reality. It would make conformance assessments more practical to their writers and readers and simplify monitoring by governments.

I feel the balance between theoretical purity and practical need has shifted.

Requirements for a new definition

When we set off thinking about views, we discussed requirements, including that we want “views” to:

Not confuse people who have an existing understanding of the word ‘view’, which is a word used by many, including developers (like views in React Native, views in Django, views that CSS view transitions transition and views in MySQL)
Not reduce accessibility requirements: a new definition shouldn't cause things to meet WCAG that don't today.
‘Work’ for a variety of different contexts, like web pages, (native) applications, VR/AR and documents (I know, a long wishlist)
Useful for people who do conformance assessments (accessibility specialists/consultants), or use them in some way (designers, developers, monitoring agencies, judges in some areas).

Steve Faulkner's suggestion

As mentioned, there is an existing draft definition in the latest WCAG 3 draft. I agree with Steve Faulker that it is wooly.

What the exact definition needs to be is yet to be determined, but after the initial (less-wooly) definition we presented to the Working Group, Steve proposed to base the definition around “change of context”.

Steve's proposed definition:

Conformance scope that includes all content visually and programmatically available without a change of context

In addition, he suggests updating “change of context” to be:

Major change in the content of the view that, if made without user awareness, can disorient users who are not able to view the entire view simultaneously

Changes in context include changes of:

user agent;

viewport;

content that changes the meaning of the view.

A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, opening a non-modal dialog, or a tab control do not necessarily change the context.

Example: Opening a new window, opening a modal dialog, going to a new view (including anything that would look to a user as if they had moved to a new view) or significantly re-arranging the content of a view are examples of changes of context.

I like where that is going.

Subviews?

Sometimes it makes sense to talk about specific parts of a UI or view, like a modal overlay, drawer or full screen search functionality. We looked at a number of examples within the group and found we were internally conflicted about some cases, there was a lot of gray area.

For this reason, I think we should in fact not define “subview”, contrary to what we intitially thought. I'd love to know what others think, please add your thoughts to the subview part of the discussion.

Possible issues

There are some disadvantages to “view”, and we got some excellent feedback from the Working Group in our initial discussion. You can see all in the minutes of 18 February, but I'll highlight two here.

More subjectivity

Among the feedback we got from the Accessibility Guidelines Working Group, was Gregg Vanderheiden's feedback that I'll summarise as: “web page“ is objective and “view” is not.

I think he's technically correct that we lose some objectivity. But I don't think that's as much of a change to the status quo. Accessibility practioners define scopes for tests today already, and, if we're honest, subjectivity already exists in accessibility conformance reports. Bad actors can act bad today, that's not a reason to avoid making things more usable for all actors. Especially if a new term would help with clarity about accessibility or inaccessibility of products.

Besides, the cat is out of the bag already: companies and governments need other environments than web apps assessed, and whether they do that with an unambiguous but inapplicable definition for “web page” or with a broader definition for “view” is unlikely to make the difference.

In app development

In native app development, a world I’ll admit I’m not very familiar with, the word “view” seems to refer not to a whole screen or page, but to parts of it, as I understand similar to what on websites, you’d call components. I learned this when I presented some of these ideas in the Mobile Accessibility Task Force (MATF), where “page” was offered as an alternative to “web page” that could work as a unit of conformance for (native) apps.

This may get into “confusing people with existing definitions of view” territory, I am not sure what's the best way out, I worry “page” could introduce similar problems in terms of future proofing. A potential solution, from Jan Jaap de Groot, could be that a different word than view is used in a document like WCAG2Mobile, which then points at WCAG's “view” for the definition. Others I talked to suggested something similar, we could have different units of conformance for different contexts, that all point to one broader unit.

SC meaning

One issue that we didn't get to much, but that is essential: what about all the SCs that mention web pages today? The published note WCAG2ICT covers mappings from “non-web software and documents” to WCAG 2 success criteria and EN 301 549 (clause 10 and 11) harmonises with that. Mapping is not be in the scope for the task of defining “views” per se, but it deserves our attention to consider what requirements would look like if we used a word like view.

Feedback wanted

In this post, I've tried to summarise some of the discussion around “view“ it happened over the last few months. It's a lot of information, with one goal: please share your thoughts.

It doens't have to be “views”, if could be “purple zebras”, as Alastair suggested, but modernising what WCAG's unit(s) of conformance are will be more helpful to users than avoiding it.

I'd love more feedback (by email or in the GitHub discussion) on what views can be and what the potential risks are, especially from accessibility practitioners (including evaluators), folks from monitoring agencies and designers and developers who want to meet WCAG.

Originally posted as Views on views on Hidde's blog.

Reply via email

View Transitions 3d Perspective - Adam Argyle

2025-02-27T23:06:40.703Z

To give View Transitions a perspective, either:

::view-transition-image-pair(--foo) {
  perspective: 500px;
}
/* or */
::view-transition-new(--foo) {
  transform: perspective(500px);
}

Hope this finds someone well.

CSS Kaleidoscopes - Adam Argyle

2025-02-23T00:21:40.428Z

Gradients are so fun, so complex, so powerful. I just can't get enough of messing with them.

Todays post was me wanting to create a kaleidoscope type effect using linear() easing with varied durations for hopefully infinite combinations.

Here's a spiffy preview of some of the combinations:

The demo effects are thanks to linear() and @property.

Each of the demo's has a ton of fun levers to pull in the CSS. Def try changing variables, durations, easings, and more.

It's super fun.

Linear gradient kaleidoscope #

See the Pen Hot text-emphasis by Adam Argyle (@argyleink) on CodePen.

Radial gradient kaleidoscope #

See the Pen Hot text-emphasis by Adam Argyle (@argyleink) on CodePen.

Conic gradient kaleidoscope #

[YOUR FORK HERE]

Send me your Codepen fork and I'll add it here!

An Emoji Naming Convention - Adam Argyle

2025-02-20T18:16:39.738Z

There are many new places in CSS for naming. You can now quickly find yourself using the same name, which is unique, but it's unique in a context… and that's really hard to remember.

Here's a simple example:

@keyframes foo {}
@property --foo {}

.element {
  --foo: bar;
  animation: foo linear both;
  view-timeline-name: --foo;
  view-transition-name: foo;
  anchor-name: --foo;
  container-name: foo;
}

Notice too how there's dashed names and undashed… some CSS features require the dashed names while others do not. Yay.

Good news is that CSS can keep track of it all. Bad news, I'm strugglin.

Not an answer, but an answer? #

I'm not actually trying to tackle this problem with this suggestion, but… maybe I am? LOL

We could, use emoji to help delineate the intended use.

Here, keyframes, typed custom properties and font-palette-values are uniquely identified with an emoji prefix.

@keyframes 🔑-example {}
@property --﹫-example {}
@font-palette-values --🔡-example {}

This then makes it clear when you got to use them:

.element {
  --﹫-example: bar;
  animation: 🔑-example linear both;
}

So building on this, I went a little further… and have assigned emoji's for anything you can custom name:

@keyframes 🔑-example {}
@property --﹫-example {}
@font-palette-values --🔡-example {}

:root {
  --﹫-example-typed: baz;
  --🔒-example-private: foo;
  --regular-var: bar;
}

::view-transition-group(.🏘️-example) {}
::view-transition-new(🏞️-example) {}

@layer 🥞-example {
  .🤓-example-class {
    container-name: 📦-example;
    view-transition-name: 🏞️-example;
    view-transition-class: 🏘️-example;
    view-timeline-name: --📽️-example;
    anchor-name: --⚓-example;
    font-palette: --🔡-example;
    animation: 🔑-example 1s;

    > p {
      @container 📦-example (inline-size < 20ch) {
        font-size: var(--﹫-example);
      }
    }
  }
}

@layer 🥞-example-utilities {
  .🔧-utility-class,  
  .🧹-reset-class,  
  .🔍-debug-class {
    …
  }
  
  .🗣️-sr-only {}
  
  .🍱-grid {}
}

Does this work?!

Yep, perfectly valid CSS. Try it on Codepen.

Did I miss an opportunity to pick an emoji prefix?

Probably! Comment on Bluesky or Mastodon and I'll add them!

As a final mention here, I think it's a good idea to -- all your custom names, just to make it really clear they aren't internal CSS keywords.

Anchoreum - Adam Argyle

2025-02-19T20:41:57.587Z

Need a rad way to learn CSS anchor?

Look no further than anchoreum.com!

39 Today - Adam Argyle

2025-02-19T19:06:43.139Z

39 today, wheeee…

trot - Robin Rendle

2025-02-15T18:06:40.131Z

I’ve been tinkering with an iOS app for the last month or so. It’s exciting stuff! Working in Swift and moving away from the web has made my work feel all new and fresh, with so many things to learn. The project codename is Trot (for now!) and here’s some notes about what I’ve learned so far.

Leaving VSCode and the browser behind by moving into XCode has made me immediately miss DevTools. It’s so much harder to prototype when you can’t zoom into the UI and crack it open like you can in the browser.

XCode does have an equivalent of that but it’s not front and center or half as easily accessible as DevTools. This realization of losing my pal DevTools honestly made me sad as I tinkered with this app for the first time, knowing that no one will be able to explore this app in the same way they might with my website. DevTools is the great equalizer.

Swift and XCode are incredibly well built and fit so nicely together. Owning the language and the tools means that this ecosystem can do some amazing things that web frameworks and text editors could only dream of. SwiftUI sort of forces you to build everything in small chunks instead of whole screens and I’ve found that I can lean into that and let it guide how I structure the code.

This ecosystem of tools and how they overlap…well…the web really has nothing like this. For good and bad!

Next steps are difficult to find though. You can’t move without watching a million videos or reading the docs: UIKit, MapKit, SwiftUI, Motion, animations. This is true if I create a .html file in VSCode but there’s also fifteen years of tinkering I can rely on. I know what HTML and CSS is capable of so I don’t need to ask questions every thirty seconds about how to style something or move its position.

This is a good reminder that the tools look simple to us web developers but they are very much not easy for newcomers to the field.

Anyway, there’s nothing in XCode that opens a door into these worlds or shows you what’s next. Nothing hints at what’s possible. You have to leave the editor to go explore and it totally kills the flow of exploration to ask a bot or a search engine how to add padding or color every three seconds. It’s like someone is slamming a door in your face over and over again.

I wanna be like: here’s some tabs on the screen! Okay, now show me all the ways I can customize those! Or show me how to animate them! Loop through the items and filter them or list out all the appearance options and frameworks I can tinker with! Show me the doors!

Autocomplete today is insufficient and I think the main reason why folks rely on Copilot or asking a bot is because these tools are really extraordinarily bad at showing you what’s possible and then how to do it.

I LOVE not having to import things in Swift. Sure, you still import frameworks at the top of a view but it’s not like a typical React codebase where every file begins with 50 lines of junk importing stuff.

This means I can reorganize files and folders and it doesn’t matter because nothing will break. I have never liked React/Typescript — every part of that ecosystem feels clunky and obtuse — but this feature of Swift and XCode alone makes web frameworks feel like an ancient system designed by complete sadists.

Building in Swift and Xcode almost (almost!) has the same feeling of opening up a text editor and writing pure HTML. It feels light and springy in a way that no web framework ever has.

Hot take: I don’t like the merge of semantic meaning and styles within Swift though. It’s like designing a whole UI with jQuery where you’re like “Thing.color(red).padding(10)” and it means it’s harder to parse the logic from the presentation. I get why it’s like that, that Swift breaks everything down into a hierarchy, a great big tree under the hood, but it means your code is all jumbled together.

I assume Apple-folk would say there is no difference between style and presentation and logic but man…the web has taught me a different way of seeing the world and this editor, these tools, conflict with every fiber of my being. But perhaps that’s a good thing.

I realize how lazy at programming I am. I can’t take one type of data and convert it to another. I hate dealing with types and keeping things in my head across files. It all feels so fragile and precarious. I hate dealing with state because all of a sudden you introduce punctuation that makes my head spin. I don’t think logically, I hop skip and jump around and my body refuses to think like a computer or a program.

Thankfully each stumbling block can now be queried and the hive mind will respond with an accurate enough solution.

But at the lowest levels I have a very vague idea of what’s going on under the hood. For a prototype that’s ok, but if this thing gets more serious I’d want an engineer to start over. Scrap it all and go again – and that makes me feel better as I tinker. None of this matters! Wahoo!

Another thing I miss? HTML defaults. When you use an <input> or a <button> in HTML you mostly don’t have to undo things. Except for forms which have always driven me crazy that they don’t inherit the font family or what not from body. But tiny rant aside, the defaults in HTML are very smart and you can build on those defaults by changing the background, the font, etc.

In SwiftUI you can use common components like List but to tweak their behavior or appearance you have to break them down into a million pieces, hacking over them to make a slight change. Want your tabs to look a bit different and have a white background? Good luck buddy, that change is gonna take you an hour.

This discovery sucks. It’s like having a design system where you pull in a component and to change the border radius of it you have to build a whole new component out of the skeleton of the button right in front of you. I can see you! Just be round!

The design of HTML and CSS has spoiled me rotten, man.

If you get a reference to an image wrong in Swift-land then your whole app implodes and nothing will run. Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.

At least on the kinds of web projects I work on, I rarely break the browser or my text editor Zed, but with pretty high frequency XCode will freak out and crash. That kills the flow too, where I might just be changing a variable and — bang! — the preview is dead and I get a popup alert blocking my work.

It makes app development feel less stable somehow and I wish there was a way XCode could figure out the code I’m writing is gonna crash before it tried to build it — as I was typing.

Making animations in SwiftUI feels so liberating though! It is light years ahead of the web because there’s tons of really smart defaults that Apple provided in what I assume was the original operating system. Things bounce and glide and it’s real easy to get things to move in the way you want them to.

Honestly I’ve never liked animating things on the web. It’s just such as royal pain and it’s very slow. In my day job as a product designer on a big web app I tend avoid animations because they often get in the way or slow things down but most of the time it’s laziness: animations are really hard to pull off on the web and most of the time they’re not worth the effort.

But here in SwiftUI? It’s so easy to make beautiful animations that you can’t help but sprinkle them everywhere. This might also be thanks to touch input. When you touch something with your finger you expect it to respond like a physical thing in the world. And without animations that touch would feel broken as all hell.

Honestly this is changing how I’m thinking about this interface: How can movement explain where someone is in the UI? How can that help teach them what might happen next? How can this animation fade into the next one, click-clacking into each other like ripples in a lake?

It’s all super exciting if I’m honest. I haven’t felt this excited about design in a good long while. Learning new tools, new techniques, new ways to do old things.

With this project I can truly fly: I am beholden to no-one. No one can tell me my designs are impossible. No one can tell me to do more research. I can just do everything instinctively, intuitively, feel things out. Who gives a shit about efficiency? Who cares about process? I just care about making something cool and learning something new.

It’s all so quiet as I build this app and bop my head to the music. There are no quarterly goals, there are no cursed Google docs, there are no lists within lists or anxious meetings.

I like the playful nature of this project, too. In the year 2025, design at a tech company is so absurdly serious. All the joy of making things is wrenched out of the work by bureaucracy or unnecessary meetings or folks higher up the chain who are anxious about every detail. Have you done the Discovery phase of your project yet? Have you confirmed that every pixel of this screen meets the expectations of this random Google Doc? How do we know that this design will be successful, will make this number go up?

I dunno, man.

But here, on this project, the research is the work. I have to build things to learn. Writing a doc is not learning. Writing a doc is not making. Adding tickets to Linear is not research. Talking to customers for six months straight without putting pen to paper is not work. It sounds dumb and arrogant of me, but here in my room as I tinker I feel renewed by all this real work. I feel close to it, cleansed by thinking about a single problem for hours at a time without distraction.

This, right here, is the research. This is the work.

And there’s no Google doc in sight.

What I learned from migrating a Vue project from Vuex to Pinia - CSS In Real Life

2025-02-13T14:01:43.942Z

Recently I had the experience of migrating a Vue web app to a new state management library, Pinia, which was interesting from both a technical and non-technical point of view. In this article for Piccalilli I’ll share my thoughts and findings on when, why and how you might consider carrying out such a major technical migration, applicable to any large web project, and some tips and advice on migrating from Vuex to Pinia specifically.

Read the article

Debating the Merits of LLMs - CSS In Real Life

2025-02-13T14:01:43.910Z

A recently published post by the science fiction writer Robin Sloan (Is It Okay?, published 11th February 2024) ignited some examination and debate among my little corner of the web. The post asks the question of whether it’s ethical, from an individual moral standpoint to use an LLM (Large Language Model, such as Claude or GPT-4). Robin raises some important points about the trade-offs that come with LLMs, depending on their application.

If their primary application is to produce writing and other media that crowds out human composition, human production: no, it’s not okay.

He also offers an alternative view, where it could be supposed that LLMs will pave the way for “super science”, a common claim of AI advocates.

If super science is a possibility — if, say, Claude 13 can help deliver cures to a host of diseases — then, you know what? Yes, it is okay, all of it. I’m not sure what kind of person could insist that the maintenance of a media status quo trumps the eradication of, say, most cancers. Couldn’t be me. Fine, wreck the arts as we know them. We’ll invent new ones.

Here’s where I disagree with Robin’s reasoning: AI isn’t LLMs. Or not just LLMs. It’s plausible that AI (or more accurately, Machine Learning) could be a useful scientific tool, particularly when it comes to making sense of large datasets in a way no human could with any kind of accuracy, and many people are already deploying it for such purposes. This isn’t entirely without risk (I’ll save that debate for another time), but in my opinion could feasibly constitute a legitimate application of AI.

LLMs are not this. They synthesise text, which is not the same as data. Particularly when they are trained on the entire internet, which we all know includes a lot of incorrect, discriminatory and dangerous information. As Baldur Bjarnason points out:

There is no path from language modelling to super-science.

I don’t believe LLMs are entirely without utility. The company I work for designs and trains AI models for use in industrial processes and LLMs. But they are different things. In one application we (and by “we”, I mean my far cleverer colleagues) deploy models for analysing performance data from wind turbines to produce insights related to power output, deterioration and part failure, in order to enable operators to plan maintenance and optimise power generation. Here AI has the potential to help drive down costs and maximise clean energy production. It’s still early days, and it remains to be seen whether this kind of technology will be widely deployed and beneficial at a large scale, but this, to my mind, edges marginally towards the scientific potential that Robin refers to (while being a long way from, say, curing cancer). It’s not an LLM.

On the other hand, we do train LLMs for other applications, such as gleaning relevant information from thousands of disparate documents, which would be impossible to trawl through manually, and present findings in a user-friendly way. This is not a general-purpose LLM designed to regurgitate information from the entire internet, but is built from a set of highly specific training data that is relevant to the industry in which it is applied.

Both of these applications are interesting and potentially useful. But they are not the same. An LLM as described above, while useful, shouldn’t invent new information. It processes the text that already exists, not the science behind it, and if it appears to offer up something new then that should be met with the utmost scrutiny. And it remains to be seen whether they (and others like them) will be worth the extraordinary amount of energy and resources that AI demands.

By using Chat-GPT to write your essay, code or email, you are not contributing to “super science”. LLMs cannot do that. Maybe you’ll conclude that using an LLM is still worth it to make you more productive in writing code, or whatever. (And yes, I have Thoughts on this.) But once we discount “super science” from the equation, it seems to me there aren’t a whole lot of positives left.

Scroll Driven Animations Notebook - Adam Argyle

2025-02-06T06:11:40.005Z

For chill time I'm adding to this scroll driven animations notebook.

Some pretty wild stuff in there already, gettin wierder each bedtime routine.

New 404 Page - Adam Argyle

2025-02-03T00:38:11.686Z

New 404 page:

glitchtastic
VisBug loaded so you can
edit or destroy the page

New Footer Went Big - Adam Argyle

2025-02-03T00:38:11.655Z

New <footer>,
Went big.

Notes on blogging - Robin Rendle

2025-02-01T21:22:11.035Z

The ever-so-great-and-interesting Katherine answered some questions about blogging and tagged me to do the same.

Why did you start blogging in the first place?

In my late teens the web wouldn’t let me go. My favorite hobby was staying up until 2am reading smart things from smart people so very far away because it felt like an act of rebellion. Hundreds, thousands of people, writing about the web and its potential, about where it should all go next. They were so open and honest! They wrote about love and code, their struggles with their family. They wrote about trying to be better people but failing over and over again.

I was obsessed with ftrain, and devoured everything that Chloe wrote (I still miss her, even though we never met). I read travelogues and private diaries and book reviews, or breakdowns of conferences in distant cities, and I would stay up all night swooning over design blogs like The Mid-Century Modernist.

Blogging was a Great Struggle Machine, a tool to bring brilliant people into my life, and it was through that ritual where we could all be more honest with each other than we might be in person. It was exciting!

My first blog was a Wordpress theme I bought from IA all about web design. It was really embarrassing and that’s me being kind to myself. I had Big Opinions about design that were just annoying regurgitations from other smart folks. But over the years I kept tinkering, eventually making my own website, and that’s where I’ve posted things for the best part of 10 years now.

Through blogging I hope to pay something back to the community that once gave so much to me.

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?

Through blogging I learned about web design and every designer back then argued to own the means of production: own your website! Don’t use a third party blogging platform because it could all be taken down, deleted, or ransacked.

After the Bad WordPress Blog Who Shall Not Be Named, I built a blog in Jekyll before landing on Eleventy which is what I’ve used for years now. I tried other systems like Blot.im but all of them fail where Eleventy thrives. It’s easy to use, easy to customize, and I can tear it all out if I want to try something else. Also, Zach rules.

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

Mostly iA Writer on my phone. I’ve tried other editing tools to help organize things but I like a single big folder full of endless notes. That’s tied up to Dropbox so I can turn those scribbles into something more thoughtful eventually.

Once I’ve got it in a good shape I run a macOS shortcut that takes the contents of my clipboard, opens up VS Code, creates a file, and pastes it in there. But gosh if Shortcuts.app isn’t the buggiest, weirdest way to do this and continually breaks which prevents me from wanting to write.

I’ll fix it eventually, I promise.

When do you feel most inspired to write?

Early mornings. Coffee in hand. Sitting in a roomful of strangers with the rain outside. That is the perfect writing environment.

But often I feel inspired by other bloggers and web-folk. Just the other day I fell down a wondrous e-hole thanks to maya.land and the bountiful links posted everywhere on her brilliantly strange website. It made me want to make weird websites again.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

Immediately. If I don’t get a post out in the second it feels important then I know it’ll languish in drafts forever.

I’ve often looked back on a note though and realized I was too fast though, too quick to post where I was careless with the idea and could’ve expanded on it so much more. Everything I post in /stories typically takes months to write and think about though.

What’s your favourite post on your blog?

Oh, man. Reading old posts now is enjoyable because I don’t remember writing them, it feels like I’m intruding on someone else’s blog at this point. But there’s certainly a style of post that I’m now tired of and try to avoid: any writing about my day job or about code and design or how to build products is so...lame. There’s an anger in those posts that feels wasteful and I often regret writing them.

The best posts are the ones where I overshare about my life, where I let the reader in on a secret I shouldn’t be telling them. So I like this post about moving out of my apartment, I like this one about the sirens back home, I like Blunder or The computer is a feeling, or Church Going (YIKES), or Like Clockwork and Potential and Loss and A Thousand Ships. Oh, oh, I am a poem I am not software, too.

In terms of tone, pacing, visuals, and everything else though — Newsletters has been the high point probably.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

I’m endlessly redesigning this guy because it calms me but I think the heat death of the universe will arrive before I bail on Eleventy.

I do feel like my website is too visually cramped at the moment. It’s like reading on a little card or note and I always want to take up all the screen real estate that I can and really show off typographically. So I expect next month I might blow it all up and try again.

Bad At CSS With Lane Wagner - Adam Argyle

2025-01-21T16:45:53.445Z

Ep #14
🎙️ Bad At CSS Podcast

Backend dev Lane Wagner, of boot.dev and host of Backend Banter FM, guests this week sharing what do backend dev think of CSS.

⤷ badatcss.com · youtube · spotify

Change and risk - Robin Rendle

2025-01-20T19:36:17.008Z

Kelly Sutton on why his team views big front-end frameworks as a liability:

Maybe it’s the changing interest rates or political winds, but I think the “fat client” era JS-heavy frontends is on its way out. The hype around edge applications is misplaced and unnecessary for building many different flavors of successful businesses.

My translation here: what’s good for business often isn’t what’s cool or tracking at the top of the orange website or what has most likes on GitHub. A product can be extremely useful and interesting and still be on the most boring tech stack imaginable.

But also, this bit:

Change comes with risk, and changing untested code has a higher regression risk. [...] Moving more slowly is fine in many cases. But when compared to a world where that change isn’t risky (server-rendered ERB), we are suddenly paying a very pricey tax for making changes in JavaScript.

At most places I’ve worked at, any amount of change feels extremely risky and that sentiment at one point or another moves out of the codebase and into every meeting and discussion. So I think that as a small dev team, where every moment is precious, perhaps the most important thing is reliability in a codebase.

And big, overly complicated JS-heavy frontends are anything but reliable.

6 CSS Snippets Every Front-End Developer Should Know In 2025 - Adam Argyle

2025-01-19T21:28:36.998Z

2025; I think every front-end developer should know how to enable page transitions, transition a <dialog>, popover, and <details>, animate light n' dark gradient text, type safe their CSS system, and add springy easing to animation.

AI is not going to give you this CSS.

This post is a theme continuation; checkout previous years 2023 and 2024 where I shared snippets for those years.

This year, the snippets are bigger, more powerful, and leverage progressive enhancement a bit more; to help us step up to the vast UI/UX requirements of 2025.

Springy easing with `linear()` #

Sprinkle life into animations with natural looking spring and bounce easings using linear().

Using a series of linear lines to make "curves", you can create surprisingly realistic visual physics. A small amount can go a long way to adding interest and intrigue to the user experience.

In the following video, the top animation uses ease-out and the bottom uses linear(), and I think the results are quite different, the bottom being more desirable.

Here's some typical linear() easing CSS 😅:

.springy {
  transition: transform 1s
    linear(
      0,
      0.009,
      0.035 2.1%,
      0.141,
      0.281 6.7%,
      0.723 12.9%,
      0.938 16.7%,
      1.017,
      1.077,
      1.121,
      1.149 24.3%,
      1.159,
      1.163,
      1.161,
      1.154 29.9%,
      1.129 32.8%,
      1.051 39.6%,
      1.017 43.1%,
      0.991,
      0.977 51%,
      0.974 53.8%,
      0.975 57.1%,
      0.997 69.8%,
      1.003 76.9%,
      1.004 83.8%,
      1
    );
}

Yes… that's what your formatter will do to it, as if it's helpful in some way lol.

The linear() code above is not very human readable, but the machines love it. No frets, there's a few generators out there:

Tip!
Expect longer durations when using linear(). When things run long, it can be nice to make them seamlessly interruptible, making linear() a great fit for transitions and potentially troublesome as keyframes.

You could alternatively use premade CSS variables from a library like Open Props:

@import "https://unpkg.com/open-props/easings.min.css";

.springy {
  transition: transform 1s var(--ease-spring-3);
}

Easy CSS to read, comes with 5 strengths for common effects:

Try it

Try the Open Props Springs notebook!

Incrementally adopt #

This one is super easy to toss in today.

Easiest way, use the cascade (if you're into that):

/* just repeat the shorthand with adjusted easing */
.thingy {
  transition: transform 0.3s ease;
  transition: transform 0.3s linear(…);
}

/* or, target a specific property */
.thingy {
  animation-timing-function: var(--ease-1);
  animation-timing-function: var(--ease-spring-2);
}

If it knows, it knows.

Or, test for it first and scalpel apply the upgrade:

.thingy {
  transition: transform 0.3s ease;

  @supports (transition-timing-function: linear(0, 0.1, 1)) {
    transition-timing-function: var(--ease-spring-2);
  }
}

Typed custom properties #

Similar to JS variables defined with var, CSS variables defined with -- are global, loose, dynamic and flexible. This is great.

But… there are times, like when building a system, that you want to limit what goes into variables so a system can run with a reasonable amount of reliability.

Try it

In the above video, a variable is set to an invalid color. At first, this breaks the system. But, @property is added, the system remained functioning with the latest known valid color value.

Create a typed <color> CSS variable like this:

@property --color-1 {
  syntax: "<color>";
  inherits: false;
  initial-value: rebeccapurple;
}

In addition to type safety, @property defined variables can also be animated because the browser can infer the steps needed to interpolate the value change based on the assigned type.

Before @property, the browser couldn’t derive a type and discover interpolation steps, it was too complicated. Now, you give the browser a hint, and it's simple.

In 2025, y'all front-end devs should be getting familiar with defining variables with @property because it:

Formalizes CSS system interfaces
Protects CSS systems
Enables new animation powers
Can perform better when using inherits: false

Resources

View transitions for page navigation #

Y'all should know how to crossfade pages when links are clicked with this tiny view transitions snippet:

@view-transition {
  navigation: auto;
}

Try it

This is the easiest snippet to add to your site, with no downsides.

It signals your website would like to use page transitions when links are clicked, and the default transition is a crossfade.

If the browser doesn't support it, it continues as it always has; but if it does support it then you dab the page with some special sauce.

There's plenty more customization you can do, like full page animations. But the gist of this section is just to share that easy snippet and the way the feature can be progressively enhanced.

Incrementally adopt #

There's many more opportunities to add additional animations with the page transition.

A great place to start enhancing this page transition experience is to identify elements commonly found across pages, and give them a name:

.nav {
  view-transition-name: --nav;
}

.sidenav {
  view-transition-name: --sidenav;
}

This includes elements in the page transition.

They can even be different elements.

a, h1 {
  view-transition-name: --morphy;
}

By giving an <a> and an <h1> the same view-transition-name on two different pages, the browser will move and resize the page 1 element to the location and size of the page 2 element, making it look like a morph. You can of course morph between the same elements also.

Try it

There is so much more. Continue giving elements names and studying the rad examples by Bramus, and you can create experiences with motion like this:

Try it

I love the DevTools for Animations, scrubbing that full page view transition is very satisfying, and excellent for really inspecting and improving the little details.

Resources

Transition animation for `<dialog>` and `[popover]` #

In 2025, knowing your way around a <dialog> and a [popover] are table stakes. Otherwise, everyone else will be on top of you, and your wack z-index attempts will be defeated with a puny value of 1.

These are common UI elements, with no JavaScript to download, and accessibility built in. Use em and know the differences.

These two elements are projected into a layer above all the other UI called the top layer. The browser projects the elements from anywhere in the document, to the top when shown.

To transition this, there’s a few new CSS properties, for the full interruptible CSS transition user experience — transition-behavior, the @starting-style rule, and overlay.

Combining these can feel like an incantation, but that makes it great copy and paste. So here! Use the following snippet to enable cross fade transitions for both <dialog> and popover: Try it

/* enable transitions, allow-discrete, define timing */
[popover], dialog, ::backdrop {
  transition: display 1s allow-discrete, overlay 1s allow-discrete, opacity 1s;
  opacity: 0;
}

/* ON STAGE */
:popover-open,
:popover-open::backdrop,
[open],
[open]::backdrop {
  opacity: 1;
}

/* OFF STAGE */
/* starting-style for pre-positioning (enter stage from here) */
@starting-style {
  :popover-open,
  :popover-open::backdrop,
  [open],
  [open]::backdrop {
    opacity: 0;
  }
}

While this code is effective and terse, it's often not enough customization if you want to present and dismiss dialogs differently than you do popovers. Or make the entry animation different then the exit.

Transition a dialog #

Here's a <dialog> element with this barebones snippet applied. They look pretty terrible out of the box, but you can do amazing things with them.

Try it

To get started, a <dialog> element needs to be in the HTML. A <dialog> should be shown and hidden with buttons, one to show it can be in the page and one to close it should be inside the dialog.

<button onclick="demo.showModal()">…</button>

<dialog id="demo">
  <header>
    <button title="Close" onclick="demo.close()">close</button>
  </header>
</dialog>

You can enable light dismiss on a dialog and skip the close button like <dialog closedby="any">

To animate the dialog transition:

Two parts need animation: the <dialog> itself and its ::backdrop.
When a dialog is shown, display: none is changed to display: block and transition-behavior enables timing this change with our animation.
When a dialog is shown, it is cloned into the top layer, this also needs to be timed with our animation.
The [open] attribute is used to know when the dialog is open or closed. @starting-style is used during the first render as starting styles.

dialog {
  /* Exit Stage To */
  transform: translateY(-20px);

  &, &::backdrop {
    transition:
      display 1s allow-discrete,
      overlay 1s allow-discrete,
      opacity 1s ease,
      transform 1s ease;

    /* Exit Stage To */
    opacity: 0;
  }

  /* On Stage */
  &[open] {
    opacity: 1;
    transform: translateY(0px);

    &::backdrop {
      opacity: 0.8;
    }
  }

  /* Enter Stage From */
  @starting-style {
    &[open],
    &[open]::backdrop {
      opacity: 0;
    }

    &[open] {
      transform: translateY(20px);
    }
  }
}

Try it

With this snippet as a starting point, you can find three popular dialog experiences for you to take code or inspiration from /have-a-dialog.

The following video shows the excellent keyboard experience. It also demonstrates the interruptible nature of a CSS transition, so a user can close it anytime they want and always see a smooth interface.

nerdy.dev/have-a-dialog

Resources

Transition a popover #

Like a <dialog> element, a popover appears over everything else in the top layer. Light dismiss is the default, and keyboard / focus management is all done for you.

https://codepen.io/argyleink/pen/mdZXzxW

Let's bulid it.

There's an HTML aspect to implementing the UX:

<button popovertarget="pop">?</button>

<p id="pop" popover>An overlay with additional information.</p>

Also, like a <dialog> element, to animate the transition of a popover's display property and insertion into the top layer, you need to combine transition-behavior and @starting-style.

Notice with a popover, the open state isn't an attribute, it's a css pseudo-class :popover-open.

[popover] {
  &, &::backdrop {
    transition:
      display 0.5s allow-discrete,
      overlay 0.5s allow-discrete,
      opacity 0.5s,
      transform 0.5s;

    /* Exit Stage To */
    opacity: 0;
  }

  /* On Stage */
  &:popover-open {
    opacity: 1;

    &::backdrop {
      opacity: 0.5;
    }
  }

  /* Enter Stage From */
  @starting-style {
    &:popover-open,
    &:popover-open::backdrop {
      opacity: 0;
    }

    &:popover-open {
      transform: translateY(10px);
    }
  }
}

Try it

Resources

Transition animation for `<details>` #

Found on the CSS Wrapped 2024 website in the desktop layout.

The disclosure element (<details>) has been waiting for CSS primitives to unlock its animation potential for many years.

<details>
  <summary>Show disclosed content</summary>
  <p>…</p>
</details>

The details element needs to transition to height: auto from height: 0px and a way to target the slotted content it internally uses for the disclosure. The new interpolate-size feature can be used for the height animation and ::details-content for the selector.

details {
  inline-size: 50ch;

  @media (prefers-reduced-motion: no-preference) {
    interpolate-size: allow-keywords;
  }

  &::details-content {
    opacity: 0;
    block-size: 0;
    overflow-y: clip;
    transition: content-visibility 1s allow-discrete, opacity 1s, block-size 1s;
  }

  &[open]::details-content {
    opacity: 1;
    block-size: auto;
  }
}

Try it

Resources

Bonus attribute #

If you want to connect two or more details elements and have them close each other respectively, you can accomplish this with a shared name attribute on each detail element you want to be connected. Very much like a radio group.

https://developer.chrome.com/blog/styling-details

<details name="linked-disclosure">
  <summary>Show disclosed content</summary>
  <p>…</p>
</details>

<!-- name="linked-disclosure" connects these together -->

<details name="linked-disclosure>
  <summary>Show disclosed content</summary>
  <p>…</p>
</details>

Animated adaptive gradient text #

A bold headline in a design is often complimented with a gradient, helping draw the eye with intrigue and vividness.

Since 2015 the web has been able to create gradient text effects, and in the past 10 years, there have been some updates and enhancements: animation, user preferences and interpolation.

Adapting the gradient text effect to light and dark themes is easy with the prefers-color-scheme query
New animation updates enable gradient effects to go beyond spinning or moving gradient images around, but to change colors over time
New interpolation updates allow those mixes to be more vivid, rich, and interesting

https://codepen.io/argyleink/pen/vEBmZNw

@property --color-1 {
  syntax: "<color>";
  inherits: false;
  initial-value: #000;
}

@property --color-2 {
  syntax: "<color>";
  inherits: false;
  initial-value: #000;
}

@keyframes color-change {
  to {
    --color-1: var(--_color-1-to);
    --color-2: var(--_color-2-to);
  }
}

.gradient-text {
  --_space: ;

  /* light mode */
  --_color-1-from: yellow;
  --_color-1-to: orange;
  --_color-2-from: purple;
  --_color-2-to: hotpink;

  /* dark mode */
  @media (prefers-color-scheme: dark) {
    --_color-1-from: lime;
    --_color-1-to: cyan;
    --_color-2-from: cyan;
    --_color-2-to: deeppink;
  }

  --color-1: var(--_color-1-from);
  --color-2: var(--_color-2-from);

  animation: color-change 2s linear infinite alternate;

  background: linear-gradient(
    to right var(--_space),
    var(--color-1),
    var(--color-2)
  );

  /* old browser support */
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;

  /* modern browser version */
  background-clip: text;
  color: transparent;

  @supports (background: linear-gradient(in oklch, #fff, #fff)) {
    --_space: in oklch;
  }
}

That's quite a snippet 😅 How did it get to that?

Most developers making a gradient text effect are starting here:

.gradient-text {
  background: linear-gradient(to right, hotpink, cyan);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}

remove the prefixes #

The first update or enhancement is to remove the prefixes. Although, so older browsers continue to support the effect, add the unprefixed values after:

.gradient-text {
  background: linear-gradient(to right, hotpink, cyan);

  /* old browser support */
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;

  /* modern browser version */
  background-clip: text;
  color: transparent;
}

Use updated gradient interpolation spaces #

Next, improve the quality of the gradient by progressively enhancing the in interpolation syntax with CSS variables and @supports.

You could alternatively repeat the gradient definition and include in oklch in it, which would also work great and support older browsers.

.gradient-text {
  --_space: ;

  background: linear-gradient(to right var(--_space), hotpink, cyan);

  /* old browser support */
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;

  /* modern browser version */
  background-clip: text;
  color: transparent;

  @supports (background: linear-gradient(in oklch, #fff, #fff)) {
    --_space: in oklch;
  }
}

Create typed `<color>` properties #

For the gradient color animation use @property, like described in snippet #4. The typed color values can be animated inside of a gradient, like a gradient used with text.

@property --color-1 {
  syntax: "<color>";
  inherits: false;
  initial-value: #000;
}

@property --color-2 {
  syntax: "<color>";
  inherits: false;
  initial-value: #000;
}

Now --color-1 can be animated like transition: –color-1 .3s ease or used in keyframes. These values that can animate, can be used anywhere color is allowed, like in a gradient text effect.

@keyframes color-change {
  to {
    --color-1: lime --color-2: orange;
  }
}

.gradient-text {
  animation: color-change 2s linear infinite alternate;
}

Make a few props, Swap em' in a dark MQ #

To keep things declarative, I've also defined color variables to hold the colors for animation.

.gradient-text {
  --_color-1-from: yellow;
  --_color-1-to: orange;
  --_color-2-from: purple;
  --_color-2-to: hotpink;

  @media (prefers-color-scheme: dark) {
    --_color-1-from: lime;
    --_color-1-to: cyan;
    --_color-2-from: cyan;
    --_color-2-to: deeppink;
  }

  /* set our typed variables to the "from" values */
  --color-1: var(--_color-1-from);
  --color-2: var(--_color-2-from);
}

Put all those moments and reasons together, and we have arrived at the final snippet:

@property --color-1 {
  syntax: "<color>";
  inherits: false;
  initial-value: #000;
}

@property --color-2 {
  syntax: "<color>";
  inherits: false;
  initial-value: #000;
}

@keyframes color-change {
  to {
    --color-1: var(--_color-1-to);
    --color-2: var(--_color-2-to);
  }
}

.gradient-text {
  --_space: ;

  /* light mode */
  --_color-1-from: yellow;
  --_color-1-to: orange;
  --_color-2-from: purple;
  --_color-2-to: hotpink;

  /* dark mode */
  @media (prefers-color-scheme: dark) {
    --_color-1-from: lime;
    --_color-1-to: cyan;
    --_color-2-from: cyan;
    --_color-2-to: deeppink;
  }

  --color-1: var(--_color-1-from);
  --color-2: var(--_color-2-from);

  animation: color-change 2s linear infinite alternate;

  background: linear-gradient(
    to right var(--_space),
    var(--color-1),
    var(--color-2)
  );

  /* old browser support */
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;

  /* modern browser version */
  background-clip: text;
  color: transparent;

  @supports (background: linear-gradient(in oklch, #fff, #fff)) {
    --_space: in oklch;
  }
}

Some years these snippets are short and sweet, but not this year. Watch out for next year's article, who knows what you'll need to know!

Creating Static SVGs from GeoJSON - CSS In Real Life

2025-01-17T17:17:09.412Z

Recently I’ve been working with map data to create interactive visualisations. When working with maps it’s common to receive data as GeoJSON, a JSON format for encoding geographic features, which specifies the type of geometry and co-ordinates for the features we want to display on a map. Javascript mapping libraries such as Mapbox GL are designed to consume GeoJSON to render features on a canvas. I’m fairly accustomed to using GeoJSON in this way — for example, rendering geographic areas as different coloured polygons overlaid on a map to show varying values for different areas.

But for a recent project I decided to take a different approach. Mapbox GL is a great library that provides a lot of useful features out of the box, like zooming and panning. It’s also pretty hefty as far as libraries go, weighing in at 1.4MB un-minified. This project did not require any advanced map functionality, however, and only required the map display to be centred on a particular area, with interactive features on hover.

In the interests of minimising the JS payload for users, it made sense to render the map as a static SVG, with only minimal JS needed for interactivity. That meant I needed to convert the GeoJSON data I had been provided with to a static SVG file. In case you find yourself in a similar position, I’m going to show you how to do this using D3.js. There’s a pre-prepared example on Codepen, in case you want to skip straight to the code.

Fetching the data

We’ll use the Fetch API to fetch some hosted GeoJSON, which has the .json suffix. I’ve uploaded an example file to Codepen, which has a limit of 5MB for file assets. In a real project, the GeoJSON file might be much bigger.

We’ll use the json() response method to parse our response data, just like any other JSON response, then we’ll log it to the console. We should see our parsed data.

const geojsonUrl = 'https://assets.codepen.io/85648/map-example.json'

fetch(geojsonUrl)
  .then((response) => response.json())
  .then((data) => console.log(data))

Depending on our geographic data, our GeoJSON could take different formats. In my case, the data I want to display is a FeatureCollection, consisting of several geographic areas. Alternatively you might have a single Feature, or geographic area, and that could consist of one or more polygons.

Here is an example of a very simple GeoJSON feature. The geometry type is Point, which means it pinpoints a specific location — useful if you’re adding a marker to a map, for instance. For drawing geographic areas, the geometry type will likely be Polygon or MultiPolygon.

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [125.6, 10.1]
  },
  "properties": {
    "name": "Example location"
  }
}

Creating the SVG

Before rendering our data as an SVG path, we first need to create an empty SVG element. We could do this in HTML:

<svg width="600" height="400" viewBox="0 0 600 400"></svg>

However, since we’re going to be using D3 anyway, let’s create the SVG in Javascript, the D3 way. That makes it simple to set our SVG dimensions as variables, which we’ll use again shortly.

const dimensions = {
  width: 600,
  height: 400,
}

It also means we can wait until after the browser has successfully fetched our data and parsed the response before rendering the SVG — and gives us the option of showing a helpful error message to users in case our request fails.

We’ll use D3’s select() method to select an element to which to append our SVG. This could be the <body>, or any other element. In this case, we’ll use a <div> with an ID of wrapper.

We’ll append an SVG element, then set the width, height and viewBox attributes.

fetch(geojsonUrl)
  .then((response) => response.json())
  .then((data) => {
    d3.select('#wrapper') // The element which to append our SVG to
      .append('svg')
      .attr('width', dimensions.width)
      .attr('height', dimensions.height)
      .attr('viewBox', `0 0 ${dimensions.width} ${dimensions.height}`)
  })

Converting GeoJSON to an SVG path

Now we’re going to use D3’s geographic path generator to generate SVG path strings from our data. We’ll append a path element to the SVG and set the d attribute (the instructions for how to draw the line) from our data. The geoPath() function can render a path from a single feature or geometry, or from multiple features combined into a FeatureCollection. If we have a single feature we can create a path generator, and call it with data:

const path = d3.geoPath()

d3.select('#wrapper')
  .append('svg')
  .attr('width', dimensions.width)
  .attr('height', dimensions.height)
  .attr('viewBox', `0 0 ${dimensions.width} ${dimensions.height}`)
  .append('path') // Append a 'path' element
  .attr('d', path(data)) // Draw the path from the data

If our data consists of a FeatureCollection, we might instead need to render multiple paths. We approach this slightly differently, by binding the dataset to our SVG, then appending a path for each of the features in the FeatureCollection.

d3.select('#wrapper')
  .append('svg')
  .attr('width', dimensions.width)
  .attr('height', dimensions.height)
  .attr('viewBox', `0 0 ${dimensions.width} ${dimensions.height}`)
  .selectAll()
  .data(data.features) // Bind the features in the FeatureCollection
  .join('path')
  .attr('d', path) // We don’t need to call `path` with an argument, as we’ve already bound the data

This should create paths from our data. It also works if our data contains “MultiPolygons” — multidimensional arrays of polygons. Note, we could alternatively use only the geometry data from our features instead of the entire Feature object.

Projection and scaling

Although inspecting the SVG element in the browser might show that we’ve rendered some SVG paths, it’s likely they’ll currently be invisible to the viewer. That’s because we haven’t yet scaled them to our SVG viewbox, so they may be rendered off-canvas. We need to tell D3 how to project our map elements onto the available space.

For this we’ll transform the projection, by calling geoIdentity(), using the fitSize() method to scale it to our SVG bounding box. Our revised projection is passed in as an argument to d3.geoPath(), overriding the default projection.

const projection = d3
  .geoIdentity()
  .fitSize([dimensions.width, dimensions.height], data)

const path = d3.geoPath(projection)

This assumes the top left SVG co-ordinates should be [0, 0] — otherwise you should use fitExtent() which allows us to specify all corners of the bounding box.

Flipping the path

Now our paths should render visibly. But you might notice there’s one more issue: they are upside-down. Be careful because this might not be totally obvious with unfamiliar paths. But it was certainly noticeable with a map of the UK!

The reason for this is that standard spatial reference systems treat the y axis as pointing upwards from 0, while in the SVG co-ordinate system the y axis points downwards, with 0 at the top. Luckily D3 provides a method for reflecting our projection in the y dimension.

const projection = d3
  .geoIdentity()
  .reflectY(true) // Flip the paths in the y dimension
  .fitSize([dimensions.width, dimensions.height], data)

const path = d3.geoPath(projection)

Result

Check out the Codepen demo below to see this in action. You can replace the geojsonUrl variable with your own GeoJSON data URL to create an SVG from your own data.

See the Pen GeoJSON to SVG by Michelle Barker (@michellebarker) on CodePen.

Once I created this I was able to copy the resulting SVG code and save the static file for use in my codebase.

Common issues drawing paths from GeoJSON

When working with GeoJSON polygon data (particularly with map libraries) I sometimes get an error along the lines of “Polygons and MultiPolygons should follow the right-hand rule”. This tends to occur in GeoJSON validators, or when using a library like Mapbox. (I didn’t have this issue with the above code.) This relates to the GeoJSON specification regarding how polygons are “drawn”. It states that “A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e. exterior rings are counterclockwise, and holes are clockwise.”

There are a couple of ways to fix this:

In the browser, by uploading the file or pasting the code into the mapster-right-hand-rule-fixer tool.
Using Mapbox’s rewind package,

Both of these will output the polygons in the correct format.

Server-side generation

After implementing this in the browser I got curious about generating SVGs from GeoJSON at build-time. This didn’t take too much work, and allows me to easily update the SVG if the data changes.

We need to do this slightly differently as there is no DOM, so we can’t select elements using D3. But we can still generate the paths easily, append them to an SVG element and write it to a file.

We can still use the geoPath() and geoIdentity() methods as previously. This time, however, we’ll map over the features and return a HTML string. In addition the the d attribute, I’m giving each path a unique ID based on its properties, which will be useful for interaction.

const projection = geoIdentity()
  .reflectY(true)
  .fitSize([dimensions.width, dimensions.height], data)

const path = geoPath(projection)

const paths = data.features.map((d) => {
  return `<path id="${d.properties.name}" d="${path(d)}" />`
})

Then we just need to append those paths to the SVG element and write to a file using Node JS’s writeFile() method.

const fileData = `<svg width="${width}" height="${height}" viewBox="0 0 ${width} ${height}">${paths.join('')}</svg>`

writeFile('./src/map-svg.svg', fileData)

Here’s the full code:

import { geoPath, geoIdentity } from 'd3'
import { writeFile } from 'node:fs/promises'

const geojsonUrl = 'https://assets.codepen.io/85648/map-example.json'

const dimensions = {
  width: 600,
  height: 300,
}

fetch(geojsonUrl)
  .then((response) => response.json())
  .then(async (data) => {
    try {
      console.log('✨Generating SVG')

      const { width, height } = dimensions
      const projection = geoIdentity()
        .reflectY(true) // SVG co-ordinate system is the opposite way up, so we need to flip it
        .fitSize([dimensions.width, dimensions.height], data) // Scale to fit our SVG dimensions

      const path = geoPath(projection)

      const paths = data.features.map((d) => {
        return `<path id="${d.properties.name}" d="${path(d)}" />`
      })

      const fileData = `<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}" viewBox="0 0 ${width} ${height}">
        ${paths.join('')}
      </svg>`

      await writeFile('./src/map-svg.svg', fileData)

      console.log('Done!')
    } catch (error) {
      console.error('Error writing file')
    }
  })

See the Github gist with this code

Advanced Attr - Adam Argyle

2025-01-17T16:52:05.004Z

Advanced attr() in Chrome 133. Opening new ways to integrate with CSS from your HTML:

<li scroll-snap="start"></li>
<li scroll-snap="center"></li>

[scroll-snap] {
  scroll-snap-align: attr(scroll-snap type(*));
}

Try it & learn more from Bramus @ Chrome Developers

CSS and design systems people - BlogFlock

Let the stagger experiments begin - Adam Argyle

Staggering animation #

Staggering color #

Time to experiment #

Abandon all keyboards - Robin Rendle

Views on views - Hidde's blog

The web page

In other places

Conformance

Views

Requirements for a new definition

Steve Faulkner's suggestion

Subviews?

Possible issues

More subjectivity

In app development

SC meaning

Feedback wanted

View Transitions 3d Perspective - Adam Argyle

CSS Kaleidoscopes - Adam Argyle

Linear gradient kaleidoscope #

Radial gradient kaleidoscope #

Conic gradient kaleidoscope #

An Emoji Naming Convention - Adam Argyle

Not an answer, but an answer? #

Anchoreum - Adam Argyle

39 Today - Adam Argyle

trot - Robin Rendle

What I learned from migrating a Vue project from Vuex to Pinia - CSS In Real Life

Debating the Merits of LLMs - CSS In Real Life

Scroll Driven Animations Notebook - Adam Argyle

New 404 Page - Adam Argyle

New Footer Went Big - Adam Argyle

Notes on blogging - Robin Rendle

Why did you start blogging in the first place? #

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before? #

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog? #

When do you feel most inspired to write? #

Do you publish immediately after writing, or do you let it simmer a bit as a draft? #

What’s your favourite post on your blog? #

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature? #

Bad At CSS With Lane Wagner - Adam Argyle

Change and risk - Robin Rendle

6 CSS Snippets Every Front-End Developer Should Know In 2025 - Adam Argyle

Springy easing with linear() #

Incrementally adopt #

Typed custom properties #

View transitions for page navigation #

Incrementally adopt #

Transition animation for <dialog> and [popover] #

Transition a dialog #

Transition a popover #

Transition animation for <details> #

Bonus attribute #

Animated adaptive gradient text #

remove the prefixes #

Use updated gradient interpolation spaces #

Create typed <color> properties #

Make a few props, Swap em' in a dark MQ #

Creating Static SVGs from GeoJSON - CSS In Real Life

Fetching the data

Creating the SVG

Converting GeoJSON to an SVG path

Projection and scaling

Flipping the path

Result

Common issues drawing paths from GeoJSON

Server-side generation

Advanced Attr - Adam Argyle

Why did you start blogging in the first place?

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

When do you feel most inspired to write?

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

What’s your favourite post on your blog?

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

Springy easing with `linear()` #

Transition animation for `<dialog>` and `[popover]` #

Transition animation for `<details>` #

Create typed `<color>` properties #