I've written three posts now about pattern(): what it is, why it might matter for beginners and AI-generated CSS, and a demo module built on top of it. This one is different. It's less a tutorial and more a check-in, and a reason to keep teaching this in the open rather than writing it once and moving on.
The part that surprised me
I expected questions about syntax. I got questions about the matching itself instead. One reader asked directly how two patterns avoid matching the same phrase. Another pointed at the ambiguity tradeoff as the thing worth watching as the idea scales. Neither question was about how to write pattern(). Both were about whether it holds up.
That's the right question to be asking, and it's not fully answered yet. I know it holds up in a small module. I don't know yet how it holds up in a library with hundreds of patterns written by more than one person. That's genuinely still open, and I'd rather say that plainly than pretend the demo module settles it.
A short recap, for anyone catching up
If this is the first post of the series you've landed on:
pattern() lets you describe a piece of CSS in plain English instead of calling it by an exact name.
pattern(0.6: "rounded primary button", `
border: none;
border-radius: 8px;
padding: 10px 20px;
background: #764ba2;
color: white;
`)
.btn {
rounded primary button
}
The phrase inside .btn doesn't need to match the description exactly. It needs to score above the threshold, 0.6 here, on word similarity. Write something close enough, and it resolves. Write something unrelated, and it falls through as harmless literal text instead of breaking your build.
The earlier posts go deeper: the mechanics of pattern(), why this matters for beginners and AI-generated CSS, and patterns.fscss, a small open module you can fork.
What I'd tell a beginner trying this for the first time
Don't start by writing ten patterns. Start by writing one, for something you personally rewrite often, a card style, a button variant, whatever shows up in your own projects repeatedly. Give it a description in the words you'd actually use out loud. Then try triggering it with a slightly different phrase than the one you wrote, not the exact words, something close. If it matches, you've felt the whole idea in about two minutes. If it doesn't, lower the threshold slightly and try again. That's the entire learning curve.
The mistake to avoid is writing two patterns that are almost the same idea in almost the same words. I made this mistake myself in the first draft of patterns.fscss, two button patterns worded closely enough that matching between them was genuinely unclear. It's an easy trap, and the only real fix is noticing it and rewording, not a cleverer algorithm.
Where this goes next
I don't have a roadmap to announce. What I have is an open module and an open question about how well description-based matching holds up at scale. If you try pattern() on something real, whether it works cleanly or breaks in an interesting way, I'd rather hear about the break. That's more useful to the next person reading this series than another polished example would be.
Repo: github.com/fscss-ttr/patterns.fscss
Docs: fscss.devtem.org/pattern
Extension visualstudio
Top comments (0)