DEV Community: FSCSS tutorial

Building Circular UI with circle-progress.fscss (No JavaScript)

FSCSS tutorial — Sun, 13 Sep 2026 22:07:52 +0000

Circular progress, pie charts, and step rings usually mean SVG path math or a chart library.

circle-progress.fscss does it with pure CSS — conic-gradient, masks, and FSCSS @define helpers.

Repo: Figsh/Circle-progress.fscss

What you get

Component	Define
Progress ring	`@circle-progress`
Solid pie	`@circle-pie`
Multi-slice pie	`@circle-pie-multi`
Steps ring	`@circle-steps`
Nested rings	Compose by nesting elements

All driven by CSS variables. Change --progress-value and the arc follows.

Setup

Option A — runtime (quick / prototyping)

<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.1/runtime.min.js" defer></script>

Option B — CLI compile (production)
It works well with FSCSS vscode extention

npm install -g fscss
fscss styles.fscss styles.css

Import the module:

@import((*) from circle-progress)

@progress-root()
@circle-progress(.progress-circle)

Full sample page:

samples/example.html

1. Progress ring

<div class="progress-circle p72">72%</div>

.p72 { @progress-range(72) }

Under the hood: a conic-gradient draws the arc, a radial mask cuts the hole, and a small tip marker rotates with the value.

2. Color override

.p41 {
  @progress-range(41)
  --progress-color-arc: #4d9fff;
  --progress-color-glow: rgba(77, 159, 255, 0.45);
}

Same component — only tokens change.

.p88 {
  @progress-range(88)
  --progress-color-arc: #ffb830;
  --progress-color-glow: rgba(255, 184, 48, 0.4);
}

3. Pie slice

<div class="circle-pie p30">30%</div>

@circle-pie(.circle-pie)
.p30 { @progress-range(30) --progress-color-arc: #ff5070; }

No mask — the conic fill is the whole disk.

4. Multi pie

<div class="circle-pie-multi pie-a"></div>

@circle-pie-multi(.circle-pie-multi)

.pie-a {
  --pie-a: 30;
  --pie-b: 25;
  --pie-c: 20;
  --pie-d: 15;
}

Four slices from four percentage tokens.

5. Steps ring

<div class="circle-steps steps-5">5/8</div>

@circle-steps(.circle-steps)
.steps-5 { @steps-done(5) @steps-total(8) }

.steps-3 {
  @steps-done(3)
  @steps-total(6)
  --progress-color-arc: #9d7eff;
}

6. Nested rings

<div class="progress-circle p72" style="--progress-size:200px">
  <div class="progress-circle p41"
       style="--progress-size:120px;--progress-stroke:10px">
    41
  </div>
</div>

Same define, different size/stroke on the child — composition without new APIs.

Mental model

Tokens — @progress-root() sets size, stroke, colors, value.
Shape — one @define per pattern (ring, pie, steps).
Value — @progress-range(n) or --progress-value.
Theme — override --progress-color-arc / --progress-color-glow.

No SVG paths. No chart library. Change a variable, the circle updates.

When to use runtime vs CLI

Use case	Prefer
Demos, CodePen, quick tests	CDN runtime
Production, static deploy	CLI compile to plain CSS

Runtime keeps FSCSS syntax in the page. CLI ships zero-runtime CSS.

Try it

Clone or copy from the repo and open the sample:

github.com/Figsh/Circle-progress.fscss

Sample: samples/example.html

Swap values, nest rings, add a pie — same module, different tokens.

Built with FSCSS @define · pure CSS circular UI

Styling Deeply Nested divs with One FSCSS Array Loop (No More Hand-Writing Selectors)

FSCSS tutorial — Fri, 11 Sep 2026 17:08:54 +0000

Writing nested selectors by hand is painful.

div { background: orange; }
div div { background: purple; }
div div div { background: indigo; }
/* …and it gets worse the deeper you go */

FSCSS gives us a clean way to generate the entire chain in a single loop using @arr + rpt().

The Problem

You have a simple nested structure:

<div>1
  <div>2
    <div>3</div>
  </div>
</div>

You want each level to have a different background color (and maybe padding, border-radius, etc.) without writing the selectors manually.

The One-Loop Solution

<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>

<style>
@arr colors[orange, purple, indigo]
@arr levels[count(3, 1)]          /* → 1, 2, 3 */

rpt(@arr.levels[], "div ") {      /* builds "div ", "div div ", "div div div " */
  background: @arr.colors[@arr.levels[]];
  padding: 10px;
  border-radius: 10px;
  color: #fff;
  margin: 8px;
}
</style>

That’s it.

What Gets Generated

div {
  background: orange;
  padding: 10px;
  border-radius: 10px;
  color: #fff;
  margin: 8px;
}

div div {
  background: purple;
  /* same properties */
}

div div div {
  background: indigo;
  /* same properties */
}

How It Works

@arr levels[count(3, 1)] creates the numbers 1, 2, 3.
rpt(@arr.levels[], "div ") repeats the string "div " according to the current level.
Inside the rule, @arr.colors[@arr.levels[]] picks the matching color (arrays are 1-indexed).
FSCSS expands the whole block once for every item in the array — one clean loop.

Easy Variations

Change depth

Just update the count() and the colors array:

@arr colors[tomato, coral, salmon, crimson]
@arr levels[count(4, 1)]

Use child combinator instead of descendant

rpt(@arr.levels[], "div > ") {
  /* now generates div >, div > div >, etc. */
}

Add more properties or even different values per level

You can reference the level index for anything — font-size, opacity, animation-delay, etc.

Why This Feels Good

Zero repetitive typing
Depth and colors stay in sync
Still pure CSS after compilation
Works with the browser runtime or the CLI

Hand-writing nested selectors used to be a small but annoying chore. With FSCSS arrays + rpt(), it becomes a one-liner pattern you can reuse anytime.

Full: https://fscss.devtem.org/nested-loop

Building an FSCSS Module: How Easy Is It, Really?

FSCSS — Tue, 08 Sep 2026 23:05:31 +0000

Building a basic FSCSS module is relatively easy, especially if you already know CSS and the core FSCSS syntax (@define, arrays/@arr, @use, imports). Getting to a polished, reusable visual component takes a bit more care to avoid a few silent pitfalls, but the ecosystem provides clear patterns and a checklist that make the whole process approachable.

What an FSCSS Module Is

FSCSS (Figured Shorthand Cascading Style Sheets) is a lightweight CSS preprocessor. A module is essentially a .fscss file containing reusable style generators defined with @define, think of them as mixins, macros, or functions. Nothing runs automatically on import. You explicitly call the definitions you want. This keeps output small and gives you full control over what actually compiles.

Here's a simple utility module:

@define radius-util(){`
  .radius-0 { border-radius: 0; }
  @arr radius[count(200)]
  .radius-@arr.radius[] {
    border-radius: @arr.radius[]px;
  }
`}

Import and use it:

@import((radius-util) from "./spacing-utils.fscss")
@radius-util()

That's enough to generate hundreds of utility classes with very little code.

Recommended Structure for Solid Modules

Existing modules, along with the official write-up on converting raw CSS components into modules, converge on the same shape:

Root tokens mixin. One @define that writes the needed CSS custom properties, usually onto :root or a scoped selector. Call it once, first.
Scoped base/reset. Tied to the component's own selector, never a bare global *.
Structural mixins. One per visual piece, each taking a selector parameter so it stays reusable.
One-call preset/composite. Wires the pieces together for the common case while leaving the individual mixins available on their own.

How Easy Is It in Practice?

Basic utilities and generators: very easy. Arrays plus @define let you produce large sets of classes in a few lines.

Component-style modules (charts, forms, animated waves, and similar): still straightforward once you follow the patterns, but the compiler is often silent on mistakes. The common gotchas:

Accidentally nesting selectors so styles compile but never match anything.
Declaring a parameter that's never referenced with @use(...), which quietly becomes a no-op.
count() needing a literal number at compile time, not an expression.
Missing module-specific prefixes on keyframes or custom properties, which causes collisions later when multiple modules share a page.
Loops needing the array reference in selector position, followed by a block, to actually trigger.

A useful debugging habit here: drop exec(_log, "message") around expansions to see exactly what the compiler produced.

Where This Comes From

There's an official experience write-up and checklist covering exactly these points, rooted in the process of turning real CSS components into siri-wave.fscss and flux-wave.fscss. Following existing modules alongside that checklist makes the process repeatable and low-friction, instead of re-debugging the same issues from scratch each time.

If you're comfortable writing CSS and willing to study one or two existing modules plus the modular system docs, building a useful FSCSS module is easy for simple cases and only moderately more involved for polished, shareable ones. The design deliberately favors small, composable, on-demand generators over heavy monolithic stylesheets, and the import system makes sharing and reusing modules simple.

write-up: fscss.devtem.org/building-fscss-modules

FSCSS Array Loops: Generating Repeated CSS Rules with @arr

FSCSS tutorial — Tue, 08 Sep 2026 15:00:09 +0000

One of the most useful tools in FSCSS for cutting down repetitive CSS is the array system. Arrays let you store ordered lists of values and expand them into repeated rules automatically, instead of writing five or six nearly identical blocks by hand.

This post walks through how @arr works, how the loop trigger behaves, and the pattern used in real FSCSS modules like siri-wave.fscss.

Declaring Arrays

Arrays in FSCSS are 1-indexed and string-native. The first item is [1], not [0].

@arr colors[magenta, cyan, green, purple, orange, blue]
@arr delays[0.1s, 0.25s, 0.45s, 0.15s, 0.35s, 0.55s]
@arr indexes[count(6,1)]   /* generates 1,2,3,4,5,6 */

count(n, start) is the standard way to generate a numeric index array. You can also declare literal lists of any CSS value type: colors, sizes, times, strings.

Accessing Individual Items

background: @arr.colors[1];      /* magenta */
animation-delay: @arr.delays[3]; /* 0.45s */

The Loop Trigger: Empty Brackets

The core feature is the empty bracket syntax, @arr.name[].

When FSCSS sees @arr.name[] inside a selector that's followed by a block, it expands the rule once for every item in the array.

@arr delays[0.1s, 0.3s, 0.5s]
@arr colors[#ef4444, #f59e0b, #10b981]
@arr indexes[count(3,1)]

.loading-dot:nth-child(@arr.indexes[]) {
  animation-delay: @arr.delays[@arr.indexes[]];
  background: @arr.colors[@arr.indexes[]];
}

This compiles to:

.loading-dot:nth-child(1) {
  animation-delay: 0.1s;
  background: #ef4444;
}
.loading-dot:nth-child(2) {
  animation-delay: 0.3s;
  background: #f59e0b;
}
.loading-dot:nth-child(3) {
  animation-delay: 0.5s;
  background: #10b981;
}

A Real Example: siri-wave.fscss

Here's the pattern as it's actually used in siri-wave.fscss:

@define siri-blob-colors(st:.blob){`
  @arr siri-colors[magenta, cyan, green, purple, orange, blue]
  @arr siri-colors-i[count(6,1)] 

  @siri-blob-variant(@use(st).@arr.siri-colors[@arr.siri-colors-i[]], @arr.siri-colors[@arr.siri-colors-i[]])

  @use(st){
    /* Need a block to trigger the loop */
    --siri-loop-index: @arr.siri-colors-i[];
  }
`}

Breaking down what happens:

Two parallel arrays are declared: one for values, one for indexes.
The empty [] sits inside a selector/argument that's followed by a block.
FSCSS expands the whole statement six times, once per index.
Each expansion calls @siri-blob-variant with the matching color name, producing .blob.magenta, .blob.cyan, and so on.

This index-array-plus-parallel-values pattern is the recommended way to generate multiple variants cleanly, without writing each variant out by hand.

Rules for Reliable Looping

@arr.name[] must appear in a selector position followed by a { } block. A bare reference inside a mixin argument alone won't trigger the loop reliably.
Prefer an explicit index array (count(n,1)) whenever you need to index into other arrays.
Arrays are expanded entirely at compile time. The output is plain CSS, with no runtime array logic left behind.

Array Methods

Method	What it does	Example
`.length`	Number of items	`@arr.colors!.length`
`.first` / `.last`	First / last item	`@arr.colors!.first`
`.list`	Comma-separated list	`@arr.colors!.list`
`.join(sep)`	Join with custom separator	`@arr.colors!.join(+)`
`.reverse`	Reversed list	`@arr.colors!.reverse`
`.shuffle`	Random order	`@arr.colors!.shuffle`
`.indices`	1-based index list	`@arr.colors!.indices`
`.randint`	One random value for the compile	`@arr.colors!.randint`

Short list

The Mental Model

Think of @arr.name[] as "for each item in this array, generate a rule." That's the entire mechanism behind the six colored blobs in siri-wave, generated without writing six almost-identical blocks by hand.

FSCSS isn't just a different syntax for writing CSS. It's growing into an ecosystem of reusable libraries, tools, and resources meant to make modern web development faster and less repetitive.

The siri-wave repo: siri-wave.fscss on GitHub

st-core.fscss: a chart and dashboard UI kit built entirely in CSS mixins

FSCSS tutorial — Sat, 05 Sep 2026 23:19:55 +0000

Most chart libraries hand you a JavaScript API and a bundle size to worry about. st-core.fscss takes a different route: it's a set of FSCSS mixins that compile straight to CSS, no JavaScript required to render a chart, a stat card, or a progress bar.

It's open source, and the whole thing lives in one readable source file.

What it can do right now

st-core.fscss covers the pieces you'd actually reach for on a dashboard or analytics screen:

Line and area charts, drawn with clip-path: polygon() against eight data points
Data dots placed along the line, generated automatically from an array so you don't write eight separate rules by hand
A background grid and axis labels, sized to match your data
Stat cards, with label, value, and an up/down delta built in
Progress bars, driven by a single custom property so the fill can be updated later without touching the markup
A device-frame container, if you want the whole thing to look like it's sitting inside a phone mockup

Everything reads from one shared design-token set, colors, radii, spacing, chart defaults, so a single st-root() call at the top of your stylesheet themes the whole kit.

Why it's built this way

Every piece is a plain @define mixin. Call st-chart-points(68, 59, 70, 35, 58, 22, 42, 55) with your real numbers, call st-chart-line() and st-chart-fill(), and you have a working chart, no chart.js, no canvas, no re-render logic. Update the data later by calling st-chart-points() again with new numbers, and every dot, line, and fill shifts to match.

That's the appeal for a dev workflow: you're writing CSS-shaped code the whole time. Nothing to import beyond FSCSS itself, nothing to configure beyond the parameters you pass.

Syntax highlighting

If @define, @use(), and @arr look unfamiliar in an editor with no idea what FSCSS is, the FSCSS VS Code extension fixes that. It adds proper syntax highlighting and snippets for FSCSS files, so reading or writing st-core.fscss mixins looks like reading CSS, not a wall of unhighlighted text. Worth installing before you open the source for the first time.

Where to start

The repo itself is short enough to read start to finish in one sitting, and there's a companion explainer walking through what every mixin does and why, mixin by mixin, if you'd rather understand the mechanics before you start calling them. Both beginners picking up FSCSS for the first time and developers who already know the compiler should be able to get a chart on screen within a few minutes either way.

Repo: github.com/fscss-ttr/st-core.fscss

FSCSS v1.2.0 is out: two clean entry points, full backward compatibility, and inline styles that actually compile

FSCSS tutorial — Fri, 04 Sep 2026 23:55:28 +0000

FSCSS is open source, built in the open, and free for anyone to use, extend, or pick apart. That's the whole point of it. Every release is meant to make it easier for other developers to build with, not harder. v1.2.0 is the clearest example of that yet.

What shipped

Previous versions of FSCSS scattered their browser-facing files across the package: /e/exec.js, /exec.js, /xfscss.js, /xfscss.min.js, and more. Depending on what you needed, you'd end up guessing which file was the right one to load.

v1.2.0 consolidates all of that into two public entry points:

<!-- Auto-run, for plain HTML pages -->
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>

// Manual control, for tooling and modules
import xfscss from "https://cdn.jsdelivr.net/npm/fscss@1.2.0/esm.js";

runtime.js auto-scans the page and compiles everything on load, <style> blocks, <link type="fscss"> sources, and now inline style attributes too. esm.js never auto-runs and never touches page loading, since it's meant for using FSCSS as a tool: an FSCSS-to-CSS converter, a build step, or any pipeline where you decide what gets processed and when.

Use one or the other. Never both.

Nothing breaks

This is the part worth repeating: the npm package and CLI are completely unchanged, and every method that worked in the 1.1.x line still works exactly the same way in 1.2.0. @define, @fun, @event, @arr, pattern(), all of it. The consolidation only touches the browser entry-point files. If you're compiling ahead of time with the CLI, this release changes nothing for you.

Inline styles now go through the full pipeline

This is the headline feature. From v1.2.0, style="..." attributes are compiled on boot the same way <style> blocks are:

<style>
  @define btn-style(bg: #636EE7){
    padding: 10px 20px;
    color: color-mix(#dddddd, @use(bg));
    background: @use(bg);
    border: 2px solid;
    border-radius: 25px;
    font-weight: 700;
  }
</style>

<button style="@btn-style(#1a2a4f)">Search</button>
<button style="@btn-style(#f00f00)">Search</button>

Combined with xfscss.process(), that means an inline mixin call can be recompiled at runtime and swapped straight back into the element, no rewritten CSS, no framework state:

const update = async (btn) => {
  const newStyle = await xfscss.process("@btn-style(@arr.colors!.randint)");
  btn.setAttribute("style", newStyle);
};

The full walkthrough of this: including a detail (method declared inline stay resolvable even after their declaration is cleaned out of the attribute), if you want to go deeper: FSCSS v1.2.0 lets you write mixins directly in style="...".

Why this matters for an open-source tool

None of this is about adding complexity for its own sake. FSCSS exists to cut down on repetitive CSS and give developers capabilities plain CSS doesn't have natively, and every release should make that easier to reach for, not harder to keep up with. Two entry points instead of a pile of internal files. Full compatibility instead of a migration guide. A feature that makes the JS API and the language work together instead of sitting side by side.

Open source only stays useful if the people using it can trust an upgrade won't cost them a rewrite. That's the bar this release was held to.

Get it

npm install fscss@latest

<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>

Bug reports, feature requests, and pull requests are all welcome on GitHub

FSCSS Component Architecture: A Modular, Composition-First Approach to CSS

FSCSS tutorial — Thu, 03 Sep 2026 15:58:02 +0000

FSCSS component architecture is built around a modular, composition-first model that compiles to plain CSS. It emphasizes reusable style units, design tokens, conditional logic, and selective imports—with almost no runtime JavaScript required for the final output. Components in FSCSS are treated as pure style definitions rather than framework-specific widgets, keeping stylesheets readable, highly reusable, and free of classic “mega-stylesheet” problems while still producing standard CSS that any browser understands.

Core Building Blocks

FSCSS provides a focused set of primitives for defining and composing styles:

Primitive	Purpose	Best for	Introduced / Key version
`str(name, "…")`	Named blocks of CSS declarations	Simple reusable style snippets	Core
`@fun(name){…}`	Key-value stores (design tokens)	Spacing scales, color palettes, property groups	Core
`@define name(params)`	Parameterized mixins	Themed components, variants, full structures	1.1.15+
`pattern(threshold: "desc", "…")`	Semantic / fuzzy matching	Natural-language style injection	1.1.25+
`@event name(param)`	Conditional value functions	Themes, states, calculations	Core
`@arr(name[…])`	Arrays + iteration	Generated classes, loops, scales	Core
`@import`	Selective / wildcard module loading	Modular architecture & ecosystem modules	Core

How Components Are Structured

1. Atomic / Token Layer (@fun + variables)

Design tokens sit at the foundation so every component draws from a single source of truth:

@fun(tokens) {
  primary: #2563eb;
  radius-md: 8px;
  space-4: 1rem;
  shadow-sm: 0 1px 3px rgba(0,0,0,.1);
}

2. Base Style Blocks (str() or @fun full-block)

Related declarations are grouped into reusable blocks that can be dropped into any selector:

str(card-base, "
  padding: @fun.tokens.space-4.value;
  border-radius: @fun.tokens.radius-md.value;
  box-shadow: @fun.tokens.shadow-sm.value;
  background: white;
")

3. Parameterized Components (@define)

True mixins accept arguments and can be composed freely:

@define button(bg: #2563eb, fg: white, pad: 0.75rem 1.5rem) {
  background: @use(bg);
  color: @use(fg);
  padding: @use(pad);
  border: none;
  border-radius: @fun.tokens.radius-md.value;
  cursor: pointer;
}

@define button-hover(bg) {`
  &:hover { background: @use(bg); }
`}

.btn-primary {
  @button()
  @button-hover(#1d4ed8)
}

4. Semantic / Intent-based Styles (pattern())

Styles can be described in plain language; FSCSS matches by similarity:

pattern(0.6: "elevated card with soft shadow", `
  border-radius: 12px;
  padding: 1.5rem;
  box-shadow: 0 10px 25px rgba(0,0,0,.08);
  background: white;
`)

.product-card {
  elevated card with soft shadow
}

5. Conditional & Dynamic Behavior (@event + @arr)

Themes, states, and generated variants are handled at compile time without external logic:

@event theme(mode) {
  if mode: dark { return: #0f172a; }
  el { return: #f8fafc; }
}

body {
  background: @event.theme(dark);
}

Modular Architecture & Ecosystem

FSCSS encourages splitting styles into focused modules and importing only what is needed:

@import((page-root, page-hero) from customizable)
@import((*) from form)
@import((st-chart-line, st-stat-card) from st-core)

Modules that follow this pattern:

st-core — pure-CSS charts & stat cards (data via CSS custom properties)
form — floating labels, checkboxes, switches, validation (checkbox-hack style)
circle-progress — progress rings with color logic driven by @event + @arr
customizable — page shells (nav, hero, CTA, footer, typography)
cube — pure CSS 3D cube faces with micro-effects

Each module is self-contained, token-driven, and designed so multiple modules can coexist on one page without conflicts.

Recommended Project Layout

styles/
  tokens.fscss          ← @fun + $variables
  components/
    button.fscss        ← @define + str()
    card.fscss
    form.fscss
  layouts/
    page.fscss
  main.fscss            ← selective @imports + composition

Compile with the CLI for production (fscss main.fscss dist/styles.css) so the shipped CSS has zero runtime dependency.

Key Design Principles

Composition over inheritance — stack small @defines and str() blocks.
Tokens first — everything reads from @fun or $variables.
Selective imports — pull only the mixins a page needs.
Compile-time resolution — almost all logic runs at build time and disappears from the final CSS.
Progressive enhancement — start with simple str() / @fun, then graduate to @define and pattern() as complexity grows.

This architecture keeps stylesheets readable, highly reusable, and free of the classic “mega-stylesheet” problems while still producing standard CSS that any browser understands.

How pattern() Feels a Few Weeks In

FSCSS tutorial — Tue, 01 Sep 2026 15:06:19 +0000

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

From st-core.fscss to ProvChart: Same CSS-Paint Idea, Built for Real Data

FSCSS tutorial — Wed, 26 Aug 2026 15:56:32 +0000

st-core.fscss started as an FSCSS module with a clear bet: charts can be browser paint, not a JavaScript chart runtime. No canvas. No SVG dependency for the line. Data lives in CSS custom properties; shapes are clip-path: polygon(); optional JS only writes numbers. Compiled, it’s on the order of ~0.5 kb of CSS—not a 40–150 kb chart library.

That idea spread—writeups, demos, dashboard experiments—because it matched what performance-minded frontends already wanted: first paint is the chart, crawlers see markup, updates can be variable writes with free CSS transitions.

ProvChart is not a rejection of that model. It’s what you build when the same philosophy has to survive arbitrary series lengths, multi-series layouts, and a server-side compile step—without asking every team to hand-author mixins per dataset.

What st-core actually nailed

st-core’s contract is intentionally tight and easy to teach:

Eight points: --st-p1 … --st-p8
Fixed X stops: 0% 14% 28% 42% 57% 71% 85% 100%
Mixins like @st-chart-points, @st-chart-line, @st-chart-fill, dots, stats
Optional JS: element.style.setProperty('--st-p3', '42%') → browser repaints the polygon

.chart {
  position: relative;
  height: 200px;
  /* FSCSS: @st-chart-points(20, 35, 33, 30, 48, 35, 66, 37) */
}

That is still a strong starter library for hand-built cards, marketing strips, and demos where eight samples are enough. It maximizes what the browser already does well. Nothing about ProvChart throws that away.

Where a fixed eight-point contract stops fitting

Real product data rarely arrives as “exactly eight numbers”:

Days in a month, weeks in a year, irregular sensor samples
Several series on one frame (revenue vs cost, traffic vs signups)
Automation: JSON from an API, not a mixin edited in a stylesheet

st-core’s elegance is that compile-time contract. ProvChart’s job is to keep data → variables → CSS geometry → paint when the point count and series count are decided per request, not per mixin signature.

What ProvChart changes (and what it doesn’t)

	st-core.fscss	ProvChart
Paint model	CSS variables + `clip-path` / native CSS	Same family of ideas
Point count	Eight fixed slots	Length of `series[].points` (no eight-slot ceiling)
Series	Hand composition / multi-line patterns in FSCSS	First-class multi-series, combo, bar, hbar, gauge, …
Authoring	Mixins in source / FSCSS compile	JSON → builder or Developer API
Client chart library	None	None for paint
Docs embeds	Manual / CSS	Optional `generate-svg`
Interaction	Hand dots / `attr()` patterns	Optional provchart-runtime

Unchanged belief: the chart is CSS. JavaScript should not be required to draw the shape.

Changed machinery: compilation can run on a server; geometry is generated for the payload you sent; roots are instance-scoped (classes like pc-… and variables such as --pc-{id}-s{series}-p{index}) so many charts can share a page without colliding.

There is no marketed “must be ≤ 200 points” product rule in this writeup. Practical limits are the usual ones: payload size, CSS complexity, and what stays smooth in real browsers—not an eight-argument mixin.

Server compile instead of only a `<style>` mixin

st-core path: FSCSS CLI or in-browser compile → you ship CSS you authored.

ProvChart path: send JSON, get markup:

const res = await fetch("https://provchart-api.devtem.org/api/v1/generate", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": process.env.PROVCHART_API_KEY,
  },
  body: JSON.stringify({
    type: "line",
    series: [
      { name: "Revenue", color: "#8b7bff", points: [20, 35, 45, 30, 50] },
    ],
    axisX: ["Jan", "Feb", "Mar", "Apr", "May"],
  }),
});

const data = await res.json();
// data.html + data.css → inject; first paint is the chart

Five points or fifty—it’s the same call shape. For README and Markdown surfaces, POST /api/v1/generate-svg returns SVG / data URI without requiring a chart runtime on the doc page.

provchart-runtime: interaction without owning paint

st-core already showed the interaction seed: a dot, a tooltip, data on the element, CSS doing the rest.

provchart-runtime (MIT, npm provchart-runtime) generalizes that for generated HTML charts:

Finds [data-provchart]
Skips pure SVG exports when configured
Scroll reveal, legend focus, per-point tooltips (reading generated custom properties where present)
MutationObserver for charts injected after load

<script>
  window.ProvChartRuntimeConfig = {
    tooltips: true,
    perPointTooltips: true,
    observe: true,
    excludeSvg: true,
  };
</script>
<script
  src="https://cdn.jsdelivr.net/npm/provchart-runtime@1.0.0/dist/provchart-runtime.min.js"
  defer
></script>

Additive on purpose: generate output does not depend on the runtime; the runtime does not replace the engine.

The stack, honestly drawn

st-core.fscss (open source, viral pure-CSS chart idea)
  --st-p1…p8 · fixed X-stops · mixins · ~0.5kb compiled CSS
  JS optional: write variables, CSS transitions animate polygons
        │
        ▼
ProvChart (chart.devtem.org)
  Same paint philosophy · variable-length series · multi-series types
  Builder + Developer API → static HTML/CSS (and SVG for docs)
        │
        ▼
provchart-runtime (optional)
  Tooltips / motion / legend UX on HTML charts only

Open core: github.com/fscss-ttr/st-core.fscss
Product: chart.devtem.org
Runtime: github.com/fscss-ttr/provchart-runtime

When to use which

Use st-core when…	Use ProvChart when…
You want full control in FSCSS/CSS source	Data is JSON from backends, CI, or agents
Eight points (or st-core’s patterns) fit the story	Series length and count change per view
You’re deep in the FSCSS module ecosystem	You want API keys, quotas, SVG export, dashboard builder
Maximum clarity for teaching pure CSS charts	Production multi-series, combo, gauge, automation

Many teams will use both: st-core for crafted marketing cards; ProvChart when the dataset refuses to stay eight samples long.

st-core.fscss proved a viral, high-performance idea—browser-native paint, minimal JS, no chart-library tax. ProvChart keeps that idea and removes the fixed-slot ceiling so the same belief works when the numbers come from a database, not a mixin call.

ProvChart Follow

Charts that load with the first paint and stay crawlable ProvChart generates pure HTML + CSS charts from your data

Why Readable CSS Matters More as AI Writes More of It

FSCSS tutorial — Tue, 25 Aug 2026 09:29:37 +0000

Most CSS tooling is built around one assumption: the person writing the stylesheet remembers the exact name of the thing they want. A mixin, a utility class, a function signature. Get the name slightly wrong and nothing happens, or worse, something wrong happens silently.

That assumption breaks down in two places at once right now: beginners, and AI-generated CSS. Neither is good at remembering exact names. Both are good at describing what they want.

The exact-name problem

Say you want a rounded button with a purple background. In most systems you need to already know the answer is .btn-primary, or mixin button-primary(), or whatever your team decided six months ago. If you don't know it, you either guess, search the codebase, or write it from scratch again, adding one more near-duplicate button style to the pile.

A beginner doesn't have that memorized name yet. An AI model generating CSS doesn't reliably have it either, it will confidently produce a plausible-looking class name that doesn't exist in your project, because plausible-looking is exactly what language models are good at, and existing in your specific codebase is not something they can check without help.

Both groups are, in a real sense, working from intent rather than from an exact API surface. The tooling just hasn't caught up to that.

Matching by description instead of by name

FSCSS's pattern() method takes the opposite approach. Instead of calling a style by its exact name, you describe it:

pattern(0.6: "rounded primary button", `
  border: none;
  border-radius: 8px;
  padding: 10px 20px;
  background: #764ba2;
  color: white;
  font-weight: 600;
`)

and later, anywhere in the stylesheet:

.btn {
  rounded primary button
}

The phrase doesn't need to match the description exactly. It needs to be close enough, measured by a similarity score against a threshold you set. Someone who writes rounded purple button instead of rounded primary button still gets the right result, because the words overlap enough to clear the bar.

This is a small syntax change with a real consequence: the thing being memorized shifts from an exact identifier to a rough description. Rough descriptions are the thing beginners already know how to produce, and the thing AI models are already extremely good at producing.

Why this helps beginners specifically

A new developer doesn't need to browse a component library, search for card, panel, surface, and box to guess which one your project picked, and read the source to confirm what it actually does. They write what they want in the words they'd use to ask a coworker for it. If a close-enough pattern exists, it resolves. If it doesn't, they get to write real CSS instead, which they were going to have to learn eventually anyway.

This doesn't remove the need to learn CSS. It removes the need to memorize your project's specific naming conventions before you can be productive in it.

Why this helps AI-generated CSS specifically

When a model generates @my-exact-mixin-name(), it is guessing at a name it has no way to verify against your actual codebase. When it generates soft elevated card with subtle shadow inside a selector, it is describing an outcome, and the matching happens against patterns that actually exist in your project. A wrong guess at an exact name fails silently or breaks the build. A wrong guess at a description either matches something close enough to be useful, or matches nothing and falls through as literal, harmless text, which is a far safer failure mode.

This is also why the earlier comment on the pattern() announcement post, about this being especially useful for AI-generated CSS, is worth taking seriously. Fuzzy matching by description is closer to how models actually operate than exact-name lookup ever was.

The tradeoff you have to manage

None of this is free. A pattern library is only as reliable as the distinctness of its descriptions. If two patterns describe closely related things in overlapping words, for example white button with purple label next to solid purple primary button with white label, a given phrase can score close on both, and the result depends on small wording differences rather than clear intent. This came up directly while building patterns.fscss: an early draft had two button patterns worded closely enough that matching between them was genuinely ambiguous.

The fix isn't a smarter matching algorithm. It's writing descriptions the way you'd want a beginner, or a model, to actually phrase the request, and keeping related-but-different patterns lexically distinct from each other. That discipline matters more as a pattern library grows, not less.

Where to start

If you want to see this in practice, patterns.fscss is a small demo module of cards, buttons, hover effects, and animations, all callable by description. Fork it, read how the descriptions are worded, and use it as a template for your own project's pattern library.

Pattern Feature: fscss.devtem.org/pattern

NPM: npmjs.com/package/fscss

Vscode extention: FSCSS support

How to build an FSCSS module like st-core.fscss

FSCSS tutorial — Mon, 24 Aug 2026 14:21:20 +0000

To build an FSCSS module like st-core.fscss, create a stylesheet of reusable @define mixins, expose a small public API, and compile/test it with the FSCSS CLI. st-core follows this pattern for design tokens, layout helpers, charts, stat cards, and progress bars.

1. Learn the module structure

An FSCSS module is a stylesheet of reusable style definitions that other FSCSS files can import.

A practical module should contain:

Private design tokens and helper logic
Public mixins with a consistent naming convention
Parameter defaults
Selector arguments so consumers can choose their own class names
Documentation and examples
A compiled CSS output for production

Typical project layout:

my-core.fscss
README.md
examples/
  demo.fscss
dist/
  my-core.css
package.json

2. Define a public API

Use a namespace to avoid collisions. Parameters must be read with @use(). For full rules, wrap the body in a backtick string block and target the selector with @use(selector){ ... }.

@define mc-root(root:root){`
:@use(root){
  --mc-bg: #10131a;
  --mc-surface: #191e28;
  --mc-card: #222938;
  --mc-accent: #4f9cff;
  --mc-text: #eef4ff;
  --mc-muted: #8491a7;
  --mc-radius: 12px;
  --mc-space: 20px;
  --mc-chart-line-width: 1.5px;
}
`}

Verify the exact syntax against the FSCSS version you ship against. st-core.fscss requires FSCSS 1.1.24 or later.

3. Build reusable mixins

A mixin should generate one coherent component or behavior.

Container

@define mc-container(st:body){`
  @use(st){
    width: 100%;
    max-width: 1100px;
    margin-inline: auto;
    padding: var(--mc-space);
  }
`}

Card

@define mc-card(st:.mc-card){`
  @use(st){
    background: var(--mc-card);
    border: 1px solid color-mix(in srgb, var(--mc-accent) 18%, transparent);
    border-radius: var(--mc-radius);
    padding: var(--mc-space);
    color: var(--mc-text);
  }
`}

Progress bar

@define mc-progress(st:.mc-progress, default-width: 0%){`
  @use(st){
    width: var(--mc-progress-width, @use(default-width));
    height: 8px;
    border-radius: 999px;
    background: linear-gradient(90deg, var(--mc-accent), #9bc7ff);
    transition: width 400ms ease;
  }
`}

The mixin establishes structure; CSS custom properties let individual instances override values.

4. Create a chart data mixin

st-core stores chart values in custom properties (--st-p1 … --st-p8). The fill, line, and dots inherit them. Values are supplied on a natural 0–100 scale (100 = top); the mixin inverts them for CSS coordinates.

@define mc-chart-points(
  p1: 0, p2: 0, p3: 0, p4: 0,
  p5: 0, p6: 0, p7: 0, p8: 0
){
  --mc-p1: num(100 - @use(p1))%;
  --mc-p2: num(100 - @use(p2))%;
  --mc-p3: num(100 - @use(p3))%;
  --mc-p4: num(100 - @use(p4))%;
  --mc-p5: num(100 - @use(p5))%;
  --mc-p6: num(100 - @use(p6))%;
  --mc-p7: num(100 - @use(p7))%;
  --mc-p8: num(100 - @use(p8))%;
}

5. Render the chart with CSS

Use clip-path: polygon(). This is pure CSS—no SVG, canvas, or JS charting library.

Area fill

@define mc-chart-fill(st:.mc-chart-fill){`
  @use(st){
    position: absolute;
    inset: 0;
    background: color-mix(in srgb, var(--mc-accent) 35%, transparent);
    clip-path: polygon(
      0% var(--mc-p1),
      14% var(--mc-p2),
      28% var(--mc-p3),
      42% var(--mc-p4),
      57% var(--mc-p5),
      71% var(--mc-p6),
      85% var(--mc-p7),
      100% var(--mc-p8),
      100% 100%,
      0% 100%
    );
  }
`}

Line stroke (thin polygon with return path)

@define mc-chart-line(st:.mc-chart-line){`
  @use(st){
    position: absolute;
    inset: 0;
    background: var(--mc-accent);
    filter: drop-shadow(0 0 6px var(--mc-accent));
    clip-path: polygon(
      0% var(--mc-p1),
      14% var(--mc-p2),
      28% var(--mc-p3),
      42% var(--mc-p4),
      57% var(--mc-p5),
      71% var(--mc-p6),
      85% var(--mc-p7),
      100% var(--mc-p8),
      100% calc(var(--mc-p8) + var(--mc-chart-line-width)),
      85% calc(var(--mc-p7) + var(--mc-chart-line-width)),
      71% calc(var(--mc-p6) + var(--mc-chart-line-width)),
      57% calc(var(--mc-p5) + var(--mc-chart-line-width)),
      42% calc(var(--mc-p4) + var(--mc-chart-line-width)),
      28% calc(var(--mc-p3) + var(--mc-chart-line-width)),
      14% calc(var(--mc-p2) + var(--mc-chart-line-width)),
      0% calc(var(--mc-p1) + var(--mc-chart-line-width))
    );
  }
`}

For production-quality curves you may prefer SVG or canvas; the CSS technique is ideal for small, fixed-point visualizations.

6. Import and use the module

@import((*) from my-core)

@mc-root()
@mc-card(.stat-card)
@mc-chart-fill(.chart-fill)
@mc-chart-line(.chart-line)

.chart {
  position: relative;
  width: 100%;
  height: 220px;
  overflow: hidden;
  background: var(--mc-surface);
  border-radius: var(--mc-radius);

  @mc-chart-points(20, 35, 33, 30, 48, 35, 66, 37)
}

.chart-line {
  --mc-accent: #55d6be;
}

Corresponding HTML:

<div class="stat-card">
  <strong>Revenue</strong>
  <span>$84,201</span>
</div>

<div class="chart">
  <div class="chart-fill"></div>
  <div class="chart-line"></div>
</div>

st-core uses the same consumer pattern: import the module, call the component mixins, then place the generated classes in HTML.

7. Support runtime updates

Because data lives in custom properties, JavaScript only needs to write variables:

function updateChart(chart, values) {
  values.forEach((value, index) => {
    chart.style.setProperty(
      `--mc-p${index + 1}`,
      `${100 - value}%`
    );
  });
}

updateChart(document.querySelector('.chart'), [
  40, 75, 60, 45, 80, 50, 70, 30
]);

JavaScript supplies data; CSS remains responsible for rendering.

8. Compile and test

npm install -g fscss
fscss examples/demo.fscss dist/demo.css

Test at least:

Mixins with default arguments
Mixins with custom selectors
Multiple component instances
Missing or invalid values
Responsive widths
CSS custom-property overrides
Compiled output in browsers (no FSCSS runtime)

For production, compile the module into CSS. st-core documents CDN/runtime mode for prototypes and compiled mode for deployment.

Recommended API design

@mc-root()
@mc-container(selector)
@mc-card(selector)
@mc-chart-points(values...)
@mc-chart-fill(selector)
@mc-chart-line(selector)
@mc-chart-grid(selector, rows, columns)
@mc-progress(selector, default-width)

Keep implementation details private, prefix every generated variable and class, document every parameter, and provide one minimal example per mixin. That combination is what makes a module like st-core.fscss reusable rather than merely a collection of CSS snippets.

Sources

Real source: st-core.fscss
Official @define / @use docs: fscss.devtem.org/define
Module README & patterns: st-core.fscss README

patterns.fscss: a demo module for styling CSS in plain English

FSCSS tutorial — Sun, 23 Aug 2026 00:10:15 +0000

FSCSS v1.1.25 shipped pattern() — a method that matches a plain-English phrase against a stored description and injects the matching CSS. I wrote about the mechanics of pattern() itself in an earlier post. This one is about what I built with it: patterns.fscss, a small demo module you can import today.

What it is

patterns.fscss is a pattern library. It bundles a set of design tokens and a set of pattern() definitions for common UI needs, cards, buttons, hover effects, animations, a few components, so you can write a class body like this:

.card {
  beautiful gradient hello world card
}

.btn-primary {
  solid purple primary button with white label
}

and get real CSS out, without calling a mixin by an exact name.

It is explicitly a demo. It does not try to cover every pattern you might want. It exists to show what a pattern library looks like in practice, and to give people a working repo to fork and extend.

How it's structured

The module is two @define blocks:

@define pattern-root(sel: root) {
  /* declares design tokens as CSS custom properties */
}

@define patterns(thr: 0.65) {
  /* declares the pattern library, using @use(thr) as
     the shared threshold for every pattern() call */
}

Calling @pattern-root() sets up the tokens. Calling @patterns(0.7) registers the library at whatever threshold you want. Everything after that is just writing phrases inside your selectors.

Using it

Import the published module directly:

@import((pattern-root, patterns) from patterns)

@pattern-root()
@patterns(0.7)

Or fork the repo and import your own copy, which is the better option once you start adding patterns of your own:

@import((pattern-root, patterns) from "./patterns.fscss")

A note on threshold and collisions

Every pattern in the module shares one threshold, set at the @patterns() call site. That keeps the call simple, but it means pattern descriptions need to stay lexically distinct from each other. Two descriptions that share most of their words, for example an early draft of this module had "rounded primary white button with purple text" next to "solid purple primary button with white text", can end up close enough in similarity score that which one wins depends on small wording differences in the phrase you actually write. The fix isn't a smarter algorithm, it's writing descriptions that don't overlap that much in the first place.

Contributing

The repo is set up for contribution. If you have a pattern you use often, plain-English description plus the CSS it should produce, a pull request is the way to get it in. The README has the full guidelines, including the distinctness rule above.

Repo: github.com/fscss-ttr/patterns.fscss

Open-source, MIT Licensed

DEV Community: FSCSS tutorial

Building Circular UI with circle-progress.fscss (No JavaScript)

What you get

Setup

1. Progress ring

2. Color override

3. Pie slice

4. Multi pie

5. Steps ring

6. Nested rings

Mental model

When to use runtime vs CLI

Try it

Styling Deeply Nested divs with One FSCSS Array Loop (No More Hand-Writing Selectors)

The Problem

The One-Loop Solution

What Gets Generated

How It Works

Easy Variations

Why This Feels Good

Building an FSCSS Module: How Easy Is It, Really?

What an FSCSS Module Is

Recommended Structure for Solid Modules

How Easy Is It in Practice?

Where This Comes From

FSCSS Array Loops: Generating Repeated CSS Rules with @arr

Declaring Arrays

Accessing Individual Items

The Loop Trigger: Empty Brackets

A Real Example: siri-wave.fscss

Rules for Reliable Looping

Array Methods

The Mental Model

st-core.fscss: a chart and dashboard UI kit built entirely in CSS mixins

What it can do right now

Why it's built this way

Syntax highlighting

Where to start

Repo: github.com/fscss-ttr/st-core.fscss

FSCSS v1.2.0 is out: two clean entry points, full backward compatibility, and inline styles that actually compile

What shipped

Nothing breaks

Inline styles now go through the full pipeline

Why this matters for an open-source tool

Get it

FSCSS Component Architecture: A Modular, Composition-First Approach to CSS

Core Building Blocks

How Components Are Structured

Modular Architecture & Ecosystem

Recommended Project Layout

Key Design Principles

How pattern() Feels a Few Weeks In

The part that surprised me

A short recap, for anyone catching up

What I'd tell a beginner trying this for the first time

Where this goes next

From st-core.fscss to ProvChart: Same CSS-Paint Idea, Built for Real Data

What st-core actually nailed

Where a fixed eight-point contract stops fitting

What ProvChart changes (and what it doesn’t)

Server compile instead of only a <style> mixin

provchart-runtime: interaction without owning paint

The stack, honestly drawn

When to use which

ProvChart Follow

Why Readable CSS Matters More as AI Writes More of It

The exact-name problem

Matching by description instead of by name

Why this helps beginners specifically

Why this helps AI-generated CSS specifically

The tradeoff you have to manage

Where to start

How to build an FSCSS module like st-core.fscss

1. Learn the module structure

2. Define a public API

3. Build reusable mixins

4. Create a chart data mixin

5. Render the chart with CSS

6. Import and use the module

7. Support runtime updates

Server compile instead of only a `<style>` mixin