What’s !important #12 talks about the old (testing in Safari when you don’t have Safari), the new (::checkmark), the in-between (anchor positioning but with HTML), and more.
Safari is the second most popular web browser, but is only available to Apple users. Fair enough. I mean, Apple are heavily invested in making Safari a proprietary browser that’s deeply integrated with Apple’s software and hardware. However, this makes testing websites in Safari a bit of a pain. Declan Chidlow explained what our options are in regards to testing in Safari when you don’t have Safari.
A first look at ::checkmark
Sunkanmi Fafowora gave us our first look at the ::checkmark pseudo-element, which solves the age-old problem of not (really) being able to style checkmarks. Note that this also targets the checked state indicator of radios and selects, not just checkboxes!
Different shape styles with border-shape + shape()
Managing anchor associations with data attributes and advanced attr()
This one’s actually from me! Disappointed to hear that the anchor attribute has been dropped, which would’ve provided a way of managing anchor associations using HTML, I demonstrated my alternative technique that involves managing anchor associations with data attributes and advanced attr().
I won’t spoiler the CSS, but here are the different HTML syntaxes that I explored:
<!-- anchor attribute -->
<div anchor="anchorA">Boat A</div>
<div id="anchorA">Anchor A</div>
<!-- Data attributes with custom ident (requires attr()) -->
<div data-boat="--anchorA">Boat A</div>
<div data-anchor="--anchorA">Anchor A</div>
<!-- Data attributes (requires attr() and ident()) -->
<div data-boat="anchorA">Boat A</div>
<div data-anchor="anchorA">Anchor A</div>
Take the State of CSS 2026 survey
It’s that time of the year again!
I love these “state of” surveys (especially the State of CSS 2026 survey, but I’m sure you know that already). This year feels different though, and I’m not the only one that’s noticed.
From the opening crawl:
Take a deep breath. Calm down. It’s ok if you don’t know every single new CSS property. The truth is, very few of us do.
Look, one of this survey’s goals has always been to help keep developers up to date on the latest and greatest CSS improvements. But the downside is that all this progress can sometimes feel overwhelming.
That’s why this year we made a conscious effort to reduce the number of features covered in the survey, focusing instead on the ones that matter most.
I totally get it. It’s becoming more and more difficult to keep up with CSS. My “things to check out” list just keeps getting longer! That being said, there’s never been a more exciting time to be a fan of CSS. That feeling when you learn a new feature and then two more get shipped, is overwhelming but in the best way possible.
But still, time doesn’t grow on trees, so we have to figure out which features to invest in, and that’s what these “state of” surveys are all about. And they’re going hard this year, really zeroing in on the most important ones.
But, if you have an appetite for all things CSS, I hear there’s a great blog for that!
But maybe there are a few things we can use today with what we already have.
For example, the CSS letter-spacing property adjusts the space between all characters in a block of text. Positive values add space to the right side of each glyph (in a left-to-right writing mode), and negative values shrink the width of the glyph box, causing letters to overlap and even move the other way.
The letter-spacing accepts length units, and percentage (relative to font size). It is animateable, and as we saw before, the negative values can shrink it down or reverse it. Which is something we can make use of.
Overlapping and separating letters
It’s quite easy to completely overlap the characters as a starting point and setting it’s color to transparent to visually hide it.
label {
letter-spacing: -1ch;
color: transparent;
/* etc. */
}
From there, we can reveal the text by animating that letter-spacing value to a positive value and updating the color to a visible value, like when a checkbox is :checked:
Note: The CSS ch unit is a relative length representing the width of the zero (0) glyph.
The labels go from negative letter-spacing to normal spacing and the color updates to black. Both these changes happen over a transition.
The second and third labels are given center and right text alignments and thus when negative letter spacing is applied they bundle up at the given alignment position, center and right, respectively. When letter``-``spacing goes from negative to zero (or any positive value) the letters separate from that same alignment position.
Thus, we get a text reveal effect! Let’s look at some more.
Showing and hiding text
Check this out. We can toggle a checkbox label as a fun interactive UI touch:
<!-- Simplified for brevity; additional accessibility considerations -->
<input type="checkbox" id="cb">
<label for="cb">
<span>Join the global club</span>
<span>You've begun your journey!</span>
</label>
label {
overflow: clip;
/* etc. */
}
span {
/* The first label */
&:nth-of-type(1) {
/* Default spacing: letters are fully visible */
letter-spacing: 0ch;
/* When the checkbox is checked, target this text */
:checked + * & {
/* collapse letters on top of each other, hiding them */
letter-spacing: -2ch;
text-indent: -1.5ch;
/* Use a "bouncy" cubic-bezier for spacing */
transition: 0.4s letter-spacing cubic-bezier(.8, -.5, .2, 1.4),
0.1s text-indent;
}
}
/* The second label */
&:nth-of-type(2) {
/* Initially collapsed (letters overlap) */
letter-spacing: -1ch;
color: transparent;
/* When the checkbox is checked, target this text */
:checked + * & {
/* Returns to normal spacing */
letter-spacing: 0ch;
color: black;
/* Slightly delay the appearance so it starts after the first text begins to hide */
transition:
0.4s letter-spacing cubic-bezier(.8, -.5, .2, 1.4) 0.3s,
0.8s color 0.4s;
}
}
}
When the box is checked, a negative letter-spacing value (-2ch) and text-indent value (-1.5ch) is used on the first <span> to slide it out of the container box. We use overflow: clip to completely hide the text.
Concurrently, the text in the second <span> text goes from a letter-spacing value of -1ch to 0ch, which reveals it. To hide this overlapped text at -1ch, a transparent color was given that’s turned to black when the checkbox is checked.
Using with other glyph box styling
Here’s another fun one. We can start with an acronym that reveal the full text on hover. Again, we have existing features to help us pull this off, including ::first-letter and ::first-line.
Each word in the UNICEF acronym initially has letter-spacing: -1ch to shrink the text, and color: transparent to keep the shrunk text hidden, except the ::first-letter that has color: black so it remains visible even though the rest of the text is stacked beneath it.
Now, we can target the image on :hover and select the entire text so that the letter-spacing value for each word decreases to 0ch and color: black is applied, showing what’s remaining of the words:
What else can we do?
I don’t know! But that’s where you come in. Obviously, a hypothetical ::nth-letter selector would be amazing for all kinds of text effects. But it’s neat that we can create some semblance of it today with existing features, like letter-spacing, ::first-letter, and ::first-line.
What can you cook up knowing we have these constraints?
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…https://ift.tt/p15BxtS…
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.
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.
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:
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.
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 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.
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.
