ai writing Technical Writing in the AI Age Geoff Graham on May 26, 2026 This isn’t coming out of nowhere: My apathy levels for the industry are absolutely sky high and I don’t even have a dickhead boss making me hit token targets — Andy Bell (@bell.bz) 2026-05-19T18:23:42.034Z More and more people I deeply respect and have learned a lot from over the years feel like they are speaking into a void, to the point where they are losing motivation to continue making content, which got me to write my first post on my site in over a year…www.kevinpowell.co/article/tell… — Kevin Powell (@kevinpowell.co) 2026-05-21T13:22:13.240Z It’s not fun to make tech content as much anymore, too. I’m doing some because I actually like it, but it feels like I’m shouting into a slop-driven void nearly everywhere. It’s really tiring.I get so much joy reading individual blogs and newsletters still (like yours!), at least. — Cassidy (@cassidoo.co) 2026-05-19T22:32:55.483Z I’m just 7 videos away from finishing a 45-video course about building for the web, and the fact that people are rarely choosing to learn from human-crafted content anymore therefore rendering hundreds of hours of my human effort completely pointless is burning me out catastrophically. I am a husk. — ⭑ salma (@whitep4nth3r.com) 2026-05-20T07:05:14.119Z These are all folks I deeply admire and I’d be lying if I said I disagreed with any of that. The fact is, demand for front-end technical writing has significantly dropped, and has been for some time . Just look at our stats for yourself: I’m not embarrassed to share this because it’s happening across the board. I mean, it’s the same thing over at Stack Overflow as we’ve already discussed in depth . I work with other content creators and publications and it’s also the same story. Naturally, I tend to take personal responsibility for this sort of thing, but it’s hard not to see that the root cause might be out of my hands: Source: 2025 AI Index , Stanford HAI And yes, I’m pointing squarely at AI. It’s a little unfair to say there aren’t other factors out there impacting our work and this site specifically, but let’s call a spade a spade and identify the biggest headwind. This isn’t totally about AI. It’s about technical writing in the age of AI. I have some thoughts on this and I hope it’s helpful to you humans reading. We still need technical writing The bots certainly aren’t learning new things on their own, right? They’re only as motivated as the prompt they’re given, and it’s human desire and effort that moves things forward. I want to acknowledge right away that I am not suggesting that AI is the new primary audience for technical writing. It’s real people like you with the motivation to learn that keeps this practice alive, even if your learnings become the prompts that allow AI to generate code for you. Finding your place Who (or what) are you writing for? It may be that your place in creating technical content needs a shift. For example, I’d wager that creating technical documentation is less valuable than it once was. Not only do we have a wealth of that in the specs and MDN, but those sorts of developer questions are now being answered directly in a chat that’s embedded right in the IDE. “But CSS-Tricks is full of all that!” you might say. And it’s true. We have a very extensive Almanac of CSS goodness that’s grown, evolved, and been tended since, I believe, 2009. We even expanded it just a couple years ago. That’s because I think CSS-Tricks has a clear place in the AI age… …and that’s making technical documentation more accessible to humans. Have you read the specs ? They’re dense, and by design for accuracy and clarity for browsers implementing CSS features. They are very technical explanations for very technical topics. I like to think that CSS-Tricks is that place you come to for very human explanations for very technical topics — more like sitting across the table from another developer over coffee (or kombucha, whatever). We serve the same sort of purpose but make a unique experience out of it. It’s all about lowering the barriers to access around here! But we’re also all about being a platform for great ideas. This site used to be a personal learning space for Chris Coyier when he started it way back in 2007. But that completely changed when Chris opened things up to guest authors. That’s a how I started here in 2015. And we’ve brought in 748 authors (as I write this) since then. Just think of all the great ideas, tips — and yes — tricks that have come out that we may have missed without a CSS-Tricks soapbox to share them. I’ve quite literally learned everything I know about front-end from these folks. Is it still worth it? Only you can answer that. Is it about money? Is it about popularity? Is it about craft? Is it about personal learning? Some combination of things? I’m not here to say any of those is better than the others, but there’s definitely a reason you would decide to continue writing technical pieces (or any sort of writing, really) in this age. I think I’ve made a case for why I do it. But you can still think it’s not worth doing it at all, even if you believe you have purpose in it. Maybe it’s unsustainable to run a blog or newsletter financially at this scale. Maybe other things are competing for your time. Maybe a really great new job is more attractive. Or maybe you’re simply burned out. You saw the comments at the top of this. The time, effort, and expectations of a job like this are sky high and the payoff — whatever you measure that in — might not be enough. If that’s the case, then the outcome is apathy and burnout. I certainly feel that and admit some days don’t feel as good as others. But I still think I/CSS-Tricks have a place to fill. And there’s still a good deal of personal fulfillment in that every time an article comment, email, or social mention tells us our work is helping in some way. Really. And I’d suggest letting your favorite technical writers know you enjoy and rely on their work wherever you happen to be reading them. It’s a pendulum swing of sorts No, no, no. I don’t see a future where AI suddenly disintegrates and we’re writing code entirely by hand again. What I mean is that technical writing — and creative web design as a whole — has kinda been here before. Sharing what we learn as we create new and interesting things was once totally against the grain, right? I love how Jay Hoffman documented that in our History archives : Articles that appeared on Word were one-of a kind, where the images, backgrounds and colors chosen helped facilitate the tone of a piece. These art-directed posts pulled from Levy’s signature style, a blend of 8-bit graphics and off-kilter layouts, with the chaotic bricolage of punk rock zines. Pages came alive, representing through design the personality of the post’s author. Web design was so punk rock in the 90s and early 2000s. Then it became a discipline. Now it’s becoming automated. And, as such, human web design is punk rock once again. Or at least it can be . New advice for technical writing We published a comprehensive piece with technical writing advice in 2019 . I don’t think I’d subtract or change any of it. Everything in there is still as relevant and true today as it was then. The goal is writing on a timely topic for a specific audience in the clearest way possible that’s inclusive of different learning styles. But I do think I’d add to that piece as the landscape continues to shift. My advice? Um, maybe don’t use AI For one, we know it’s not always accurate . Two, it dilutes your personal voice . Both are very detrimental to the discipline of writing. And what’s the point of giving people an AI explanation of something they can already get way more easily in their IDE? That’s exactly what leads to AI slop. But I won’t dismiss AI usage wholesale. I’ll actually caveat the whole “don’t use AI thing” to pin it specifically to writing. Because a tool like Grammarly has always been helpful, even before it was marketed as a complete AI writing suite. You don’t have to use the beefier features that practically do the writing for you to get something out of it. I tend to reach for AI to help with menial tasks: Quick spell checks, converting Markdown to HTML, keeping the publishing calendar on schedule, things like that. AI is pretty good with low-lift work that doesn’t have much or anything to do with writing. (I’d also argue that a lot of what we call “AI” today is what we called “automation” before the hype. I’m more interested in the tools that help enhance our craft, not replace it.) More real-life experiences, less documentation If you’re going to write about something, I’d lean into what AI can’t solve on its own, or at least can’t solve easily. It’s already really great at giving you the basic definition of any CSS property along with a quick code example, often pulled straight from existing technical documentation. That’s well-trodden territory unless you’re packaging it a different way. I learn best when I’m faced with a challenge, like something a client wants that I’ve never attempted before. I’d bet the dime in my pocket that’s how you learn best, too. We make mistakes and learn from them. And for technical writers, it’s the path from noob to understanding that makes all the difference. That’s the hook. That gives your readers a mental model to use in their own work — again, even if that mental model is going straight into writing AI prompts. Then again, I’m the product of the View Source generation. The same sort of way that many musicians would learn by slowing down a record player to learn chords, notes, or beats. Maybe I’m the old man shouting at clouds. You don’t have to be the authority I know there’s at least a little expectation that everything we publish on sites like CSS-Tricks are the “right” way to do this or that and that you ought to be able to copy-paste code snippets straight-up. I get that, but also don’t believe that’s a promise this site has ever made. I really do believe that CSS is poetic in the sense that there’s more than one way to do something, and the best way to do that thing is what fits your mental model the most snugly. And I believe there is real value in trying something purely for the sake of trying it . This site has always been about exploring, experimenting, and sharing along the way. And sometimes that means sharing just the germ of an idea. There’s no dogma here. The goal: be experienced, not cynical. You don’t have to be the be-all-end-all authority on a subject for permission to share. Just experience, and that’s not always the same as being the expert. All of that really to say: Learn fast, share often What you learn is going to be more meaningful to a real person than some generated replacement of s Stack Overflow answer. Did you try something and it didn’t work out? Did you try something and it did work out? Did you make a bunch of mistakes on the way to getting it right? Do you still have open questions about the thing you learned? That’s all worth sharing. That’s where the real-life experiences come from and the learning paths that you simply don’t get from generated responses claiming to have the best answer. Said another way: Solve real problems. Get into the edge cases. Leverage community knowledge. Cite generously At the end of the day, it’s all about humans helping humans. We don’t wake up one day with all the answers. We learn from the things other people learn and share, and it’s worth pointing your readers in their direction. It’s easy to want to come off as the original source of everything you publish, but my experience is that’s never the true case. We build off each other. It’s blogging at its core. Let’s build each other up the good ol’ fashioned way with hyperlinks . Forget about SEO… or even AIO We toe-dipped into SEO several years ago, but it’s never really been our jam. We’ve ridden and enjoyed the Organic Search Train forever. That’s liberating because we never really worry about keyword stuffing, click-baity headlines, or anything really optimization for that matter. We focus instead on writing for humans, good structure, and maintaining a certain voice and tone. All things Google used to care about. I say “used to care” there because that core value contains less value than ever , even if they do still claim it does . There’s no doubt about it; search traffic is gutted in favor of generated responses to queries connected to the services you use. That’s a clear hit to traffic and that’s a clear hit to the traditional ways we generate revenue that are measured by traffic analytics. And forget about whatever it is that’s called “Artificial Intelligence Optimization” ( AIO ). It’s still an evolving space of fluid and inconsistent “best” practices, like some agents keen on proposals for text-based files to help LLMs use your site that other agents, like Google, just aren’t into . Maybe it’ll become a discipline with clearer strategies, guidelines, and best practices in the future, but we just don’t know, and I’m feigning ignorance at least until the smoke clears. I’m honestly unsure whether I even care about CSS-Tricks popping up as a reference in a generated response. The landscape is evolving, and my thoughts on it have to as well. You’ve got this. I’m rooting for you. I’m rooting for all of us.

view transitions Cross-Document View Transitions: Scaling Across Hundreds of Elements Durgesh Rajubhai Pawar on May 25, 2026 In Part 1 , we covered the gotchas that bite you first: the deprecated meta tag that silently does nothing, the 4-second timeout that kills transitions without telling you, the image distortion that turns every aspect ratio change into silly putty, and the pagereveal / pageswap events that give you hooks into the transition lifecycle. All of that gets you from “nothing works” to “one element transitioning nicely between two pages.” Which feels great. For about five minutes. Then you try to build a product listing page with 48 cards that each need to morph into a detail view, and you realize the tutorials left out the hard part. This is where it gets real. Let’s scale this thing. Cross-Document View Transitions Series

The Gotchas

Nobody Mentions Scaling View Transitions Across Hundreds of Elements (You are here!) The Dream: One Line, Infinite Names In a perfect world, you’d solve the scaling problem with pure CSS. No JavaScript. No server-side loops. Just this: .card { / Generates card-1, card-2, card-3, etc. automatically / view-transition-name: ident(“card-” sibling-index()); } That’s ident() — a CSS function proposed by Bramus (who works on Chrome) to the CSS Working Group. It takes strings, integers, or other identifiers, concatenates them, and spits out a valid CSS name. Pair it with sibling-index() , which returns an element’s position among its siblings (1, 2, 3…), and you get auto-generated unique names for every element in a list. One rule. Works for 10 cards or 10,000. The CSS doesn’t care. And it’s not just view transitions. The same pattern works for scroll-timeline-name , container-name , view-timeline-name — anywhere you need unique identifiers at scale. You could even pull names from HTML attributes with attr() instead of sibling-index() , constructing identifiers like ident(“–item-” attr(id) “-tl”) . The flexibility is real. Here’s the thing: half of this equation already exists. sibling-index() shipped in Chrome 138 — you can use it today for things like staggered animations and calculated styles. The missing piece is ident() . There’s a Chrome Intent to Prototype from May 2025, which means it’s on the radar. But “on the radar” and “in your browser” are very different things. No browser ships ident() yet, and there’s no timeline for when it’ll land. So we can’t use it yet. But it’s worth knowing about because once ident() ships, a huge chunk of the complexity you’re about to see just… evaporates. Until then, here’s how you solve the same problem efficiently today — with the tools that actually exist in browsers right now. 100 Products, 100 Names, 1 Nightmare Here’s what happens when you follow a tutorial that shows one hero image transitioning between two pages and try to apply that pattern to a grid: / THE NIGHTMARE – one rule per item, forever / ::view-transition-group(card-1), ::view-transition-group(card-2), ::view-transition-group(card-3), ::view-transition-group(card-4), ::view-transition-group(card-5), ::view-transition-group(card-6), ::view-transition-group(card-7), ::view-transition-group(card-8) / … imagine 92 more of these / {

animation-duration: 0.35s; animation-timing-function: ease-out; }

::view-transition-old(card-1), ::view-transition-old(card-2), ::view-transition-old(card-3) / kill me / { object-fit: cover; } That’s what you end up with if you follow the tutorials that only show one or two named elements. They assign view-transition-name: hero to one image and call it a day. Cool. Now try building a product grid. Every view-transition-name on a page must be unique. That’s a hard rule — if two elements share a name, the browser doesn’t know which one maps to which on the next page, so it throws the whole transition out. On a listing page with 48 products, you need 48 unique names. On a photo gallery with 200 thumbnails, you need 200. The names aren’t the problem — you can generate those. The problem is that every pseudo-element selector in your CSS targets a specific name , so your animation styles explode into an unmanageable wall of selectors. This is where you need to understand the difference between two properties that sound like they do the same thing but absolutely do not. Name vs. Class: The Distinction That Changes Everything And yeah, the naming here is confusing. I’ll be honest: the first time I saw view-transition-name and view-transition-class next to each other, I thought they were interchangeable. They’re not, and the difference matters. Name = identity. It answers: “Which element on Page A is the same element on Page B?” When you give a thumbnail view-transition-name: card-7 on the grid page and give the hero image view-transition-name: card-7 on the detail page, you’re telling the browser those are the same thing and to animate between them. Names must be unique per page. Two elements can’t both be card-7 or the whole thing breaks. Class = styling hook. It answers: “How should the animation look ?” When fifty elements all have view-transition-class: card , you can write one CSS rule that controls the duration, easing, and object-fit for all of them. It’s the same mental model as CSS classes on regular elements — .btn doesn’t identify a specific button, it says “style me like a button.” Think of it like a database. The name is the primary key — unique, identifies one specific row. The class is a category column — groups rows together so you can run a query across all of them at once. Here’s what that looks like in practice: CodePen Embed Fallback There it is. Six cards, six unique names, but exactly three CSS rules handling all the animation behavior. Could be sixty cards. Could be six hundred. The CSS doesn’t change. The key line is that selector: ::view-transition-group(*.card) . The asterisk is a wildcard for the name, and .card matches the view-transition-class . It reads as “any view transition group whose element has view-transition-class: card , regardless of what its specific name is.” For cross-document multi-page application (MPA) transitions, the pattern is the same but you generate the names on the server:

/ ONE stylesheet, shared by all pages, handles every product / @view-transition { navigation: auto; }

::view-transition-group(*.card) { animation-duration: 0.35s; animation-timing-function: cubic-bezier(0.25, 0.46, 0.45, 0.94); }

::view-transition-old(.card), ::view-transition-new(.card) { object-fit: cover; } That’s the entire animation stylesheet for a site with thousands of products. Three rules. No matter how many items you have in the database, you never add another line of transition CSS. Before view-transition-class existed, people were doing horrifying things — looping through items in JavaScript to generate