DEV Community: FSCSS

How to build an analytics dashboard with FSCSS( st-core, circle-progress, and icon-mask)

FSCSS — Fri, 25 Sep 2026 08:15:16 +0000

A full walkthrough of the admin dashboard template: pure CSS charts, a traffic pie, mask icons, and a little JS for tabs and the mobile drawer — no Chart.js, no SVG charting library.

You will use

Module	Role
st-core@v2	Design tokens + revenue area/line chart
circle-progress	Traffic multi-pie
icon-mask	Sidebar / toolbar icons
FSCSS ≥ 1.2.3 (1.2.4+ recommended)	Compile or runtime

End result: responsive analytics shell (stats, chart, pie, goals, lists, table).

Architecture

index.html     → structure only
dashboard.fscss → tokens, layout, chart, pie, icons  →  dashboard.css
dashboard.js   → drawer, profile menu, --st-pN for chart ranges

FSCSS builds geometry and chrome at compile (or runtime) time.
JS only changes CSS variables when the user picks 7d / 30d / 90d.
Production: ship HTML + compiled CSS + JS (no FSCSS runtime in the browser).

1. Project files

admin-dashboard/
├── index.html
├── dashboard.fscss
├── dashboard.css    # generated
└── dashboard.js

mkdir admin-dashboard && cd admin-dashboard

2. FSCSS — modules, tokens, chart

Create dashboard.fscss.

Imports and roots

@import((*) from st-core@v2)
@import((*) from circle-progress)
@import((*) from icon-mask)

@st-root()
@progress-root()
@icon-pack()

Pulls in chart helpers, pie helpers, and icon utilities, then installs default CSS variables from each module.

Theme overrides

:root {
  --st-bg:        #0b0c10;
  --st-surface:   #12131a;
  --st-card:      #181924;
  --st-accent:    #22c55e;
  --st-text:      #f1f5f9;
  --st-muted:     #94a3b8;
  --st-border:    rgba(255,255,255,0.08);
  --st-radius-lg: 16px;

  --progress-size:   140px;
  --progress-stroke: 16px;

  @icon-color(#94a3b8)
  @icon-size(20px)
}

Green accent, dark surfaces. Icon defaults apply to .icon masks from icon-mask.

Minimal reset + shell

* { box-sizing: border-box; margin: 0; padding: 0; }

body {
  min-height: 100vh;
  background: var(--st-bg);
  color: var(--st-text);
  font-family: system-ui, sans-serif;
  display: flex;
}

.sidebar {
  width: 240px;
  background: var(--st-surface);
  border-right: 1px solid var(--st-border);
  padding: 24px 16px;
  position: sticky;
  top: 0;
  height: 100vh;
}

.main {
  flex: 1;
  padding: 24px 28px;
  overflow-y: auto;
}

.card {
  background: var(--st-card);
  border: 1px solid var(--st-border);
  border-radius: var(--st-radius-lg);
  padding: 22px;
}

Flex body: sidebar + main. Cards use st-core-style tokens.

Revenue chart (st-core@v2)

@arr data7d[42, 58, 65, 60, 78, 70, 92]

@st-chart-fill(.rev-fill, data7d)
@st-chart-line(.rev-line, data7d)
@st-chart-grid(.rev-grid, 5, 7)

.chart {
  @st-chart-points(data7d)
  position: relative;
  height: 220px;
}

.rev-fill {
  --st-accent: #22c55e;
  opacity: 0.22;
  transition: clip-path 0.7s cubic-bezier(0.4, 0, 0.2, 1);
}

.rev-line {
  --st-accent: #22c55e;
  @st-chart-line-width(2.5px)
  transition: clip-path 0.7s cubic-bezier(0.4, 0, 0.2, 1);
}

What this does

@arr data7d[…] — compile-time length (7 stops).
@st-chart-points — writes --st-p1…7 as inverted Y (num(100 - v)%).
Fill + line — clip-path polygons from those variables.
JS can later overwrite --st-pN; CSS transitions the shape.

Markup for the chart:

<div class="chart" id="revenueChart">
  <div class="rev-fill"></div>
  <div class="rev-line"></div>
  <div class="rev-grid"></div>
</div>

Traffic pie (circle-progress)

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

.traffic-pie {
  --progress-size: 140px;
  --pie-a: 45;
  --pie-b: 30;
  --pie-c: 15;
  --pie-d: 10;
  --progress-color-arc: #22c55e;
  --progress-arc-2: #3b82f6;
  --progress-arc-3: #8b5cf6;
  --progress-arc-4: #f59e0b;
  position: relative;
}

Four slices from CSS variables. Optional hole with a pseudo-element so a center label can sit on top.

Icons (icon-mask)

.logo .icon { @icon-color(#22c55e) @icon-size(24px) }
.nav a.active .icon { @icon-color(#22c55e) }

In HTML, icons are empty spans with classes the pack understands:

<span class="icon icon-home"></span>
<span class="icon icon-chart"></span>

Responsive sidebar

@media (max-width: 1100px) {
  .menu-btn { display: grid; }
  .sidebar {
    position: fixed;
    left: 0;
    top: 0;
    z-index: 100;
    transform: translateX(-100%);
    transition: transform 0.25s ease;
  }
  .sidebar.open { transform: translateX(0); }
  .grid { grid-template-columns: 1fr; }
}

JS toggles .open on the sidebar and backdrop.

3. HTML — structure only

Skeleton of index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Analytics Overview</title>

  <!-- Dev / preview: runtime -->
  <script src="https://cdn.jsdelivr.net/npm/fscss@1.2.4/runtime.min.js" async></script>
  <link type="text/fscss" href="dashboard.fscss">

  <!-- Production after CLI:
  <link rel="stylesheet" href="dashboard.css">
  -->
</head>
<body>
  <div class="sidebar-backdrop" id="sidebarBackdrop"></div>

  <aside class="sidebar" id="sidebar">
    <div class="logo">
      <span class="icon icon-chart"></span> Figsh
    </div>
    <nav class="nav">
      <a href="#" class="active"><span class="icon icon-home"></span> Dashboard</a>
      <a href="#"><span class="icon icon-chart"></span> Analytics</a>
      <!-- more links -->
    </nav>
  </aside>

  <main class="main">
    <div class="topbar">
      <button class="menu-btn" id="menuBtn" type="button" aria-label="Open menu">
        <span class="icon icon-tasks"></span>
      </button>
      <h1>Analytics Overview</h1>
      <!-- search, notifications, profile -->
    </div>

    <div class="stats">
      <div class="stat-card">
        <div class="label">Total Sales</div>
        <div class="value">$48,290</div>
        <div class="delta up">↑ 12.5%</div>
      </div>
      <!-- more stats -->
    </div>

    <div class="grid">
      <div class="card">
        <div class="tabs">
          <button class="tab active" data-range="7d" type="button">7d</button>
          <button class="tab" data-range="30d" type="button">30d</button>
          <button class="tab" data-range="90d" type="button">90d</button>
        </div>
        <div class="chart" id="revenueChart">
          <div class="rev-fill"></div>
          <div class="rev-line"></div>
          <div class="rev-grid"></div>
        </div>
        <div class="x-labels" id="xLabels"><!-- filled by JS --></div>
      </div>

      <div class="card">
        <div class="traffic-pie">
          <div class="pie-center"><strong>100</strong><br><span>Total</span></div>
        </div>
        <!-- legend -->
      </div>
    </div>
  </main>

  <script src="dashboard.js"></script>
</body>
</html>

No chart config objects in HTML — only classes and a few ids for JS.

4. JavaScript — behavior + data → variables

dashboard.js does three jobs.

Mobile drawer

const menuBtn = document.getElementById('menuBtn');
const sidebar = document.getElementById('sidebar');
const backdrop = document.getElementById('sidebarBackdrop');

function openSidebar() {
  sidebar.classList.add('open');
  backdrop.classList.add('open');
}
function closeSidebar() {
  sidebar.classList.remove('open');
  backdrop.classList.remove('open');
}

menuBtn?.addEventListener('click', () => {
  sidebar.classList.contains('open') ? closeSidebar() : openSidebar();
});
backdrop?.addEventListener('click', closeSidebar);

Optional: swipe-to-close and edge-swipe-to-open on touch devices (same idea as the full template).

Chart ranges → `--st-pN`

const datasets = {
  '7d': {
    values: [42, 58, 65, 60, 78, 70, 92],
    labels: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'],
  },
  '30d': {
    values: [35, 48, 55, 62, 58, 70, 75, 68, 80, 85],
    labels: ['W1', 'W2', /* … */],
  },
  // '90d': …
};

function updateChart(range) {
  const data = datasets[range];
  const style = data.values
    .map((v, i) => `--st-p${i + 1}: ${100 - v}%;`)
    .join(' ');

  document.getElementById('revenueChart').style.cssText = style;
  document.getElementById('xLabels').innerHTML =
    data.labels.map((l) => `<span>${l}</span>`).join('');
}

document.querySelectorAll('.tab').forEach((tab) => {
  tab.addEventListener('click', () => {
    document.querySelectorAll('.tab').forEach((t) => t.classList.remove('active'));
    tab.classList.add('active');
    updateChart(tab.dataset.range);
  });
});

updateChart('7d');

Why 100 - v?

CSS 0% is the top of the box. A high score should sit high on the chart, so human 90 becomes --st-p*: 10%.

Length note: polygon stop count is fixed when you compile from @arr data7d (7 points). Extra --st-p8… for longer series need a longer compile-time array (or a max-N template). Tabs still update values and labels; see st-core docs for fixed vs bounded length.

Profile dropdown

const profileBtn = document.getElementById('profileBtn');
const dropdown = document.getElementById('profileDropdown');

profileBtn?.addEventListener('click', (e) => {
  e.stopPropagation();
  dropdown.classList.toggle('open');
});
document.addEventListener('click', () => dropdown?.classList.remove('open'));

5. Compile for production

npm install -g fscss@1.2.4
fscss dashboard.fscss dashboard.css

In index.html:

<link rel="stylesheet" href="dashboard.css">
<!-- remove runtime script and type="text/fscss" -->

CI option: GitHub Action on templates/**/*.fscss that runs the same command and commits dashboard.css for static hosting.

6. Mental model

Layer	Responsibility
FSCSS modules	Tokens, chart polygons, pie, icons
Your `.fscss`	Layout, theme, wire modules to classes
HTML	Regions and class names
JS	UX + map `number[]` → `--st-pN`

You are not driving a chart API. You are updating design tokens that already-drawn CSS shapes read.

7. Next steps

Swap green tokens for your brand.
Point datasets at a real API.
Reuse the same CSS in Svelte/React by setting style / cssText from props (see st-core integration/svelte).
Add React/Next wrappers later; the compile step stays the same.

Template & preview


Live preview	hub.devtem.org/st-core.fscss/templates/admin-dashboard/
Template source	github.com/fscss-ttr/st-core.fscss/tree/main/templates/admin-dashboard
st-core	github.com/fscss-ttr/st-core.fscss
circle-progress	github.com/Figsh/Circle-progress.fscss

Clone the template folder, run with runtime for a quick look, then compile to CSS for production.

Build the chrome and charts in FSCSS. Keep HTML boring. Let JS only move the numbers.

patterns.fscss: Write CSS in Plain English

FSCSS — Wed, 23 Sep 2026 16:30:13 +0000

Ship real UI from role-based phrases. No hand-rolled component sheets. FSCSS pattern() matches what you type, injects CSS, and lets you pass colors, sizes, and durations in the same line.

FSCSS version 1.2.4+

The idea

You register a short description and a CSS template once. Elsewhere in the stylesheet you write a normal-looking phrase. If the phrase scores high enough against that description, the template is expanded in place.

/* Library */
pattern(0.65: "solid filled primary button", `
  background: var(--pattern-accent);
  background: @match((?:bg|background):\s*([#\w().%-]+));
  color: var(--pattern-text-on-accent);
  /* … */
`)

/* App */
.btn-primary {
  solid filled primary button bg: #344466
}

No mixin name to remember. No build step required if you use the browser runtime. For production, compile once with the CLI (or a GitHub Action) and ship plain CSS.

Feature overview

1. Role-based descriptions

Patterns are named by role, not by a fixed color:

Good	Avoid
`solid filled primary button`	`solid purple primary button with white label`
`ghost outline button with accent border`	`blue outline button`

Colors live in design tokens (pattern-root) or arrive through @match when the caller supplies them. Role words stay stable when your palette changes; color words in the description go stale and pollute matching.

2. `@match` — parameters in the phrase

Inside a template, @match(regex) runs on the caller’s line. First capturing group wins.

background: var(--pattern-accent);
background: @match((?:bg|background):\s*([#\w().%-]+));

Phrase	Result
`solid filled primary button`	default token
`solid filled primary button bg: #0ea5e9`	override `#0ea5e9`

Labels used across the module include: bg / background, color / text / label, from / to, border, radius, lift, scale, duration / time, size, ring, min / max / pad / gap, thumb, fill, lines, and more.

Regexes stay simple ([#\w().%-]+ for colors, length patterns for sizes). FSCSS 1.2.4 rejects hostile nested quantifiers before compile.

3. Cascade fallbacks (no empty custom properties)

When a match fails, the engine can emit an empty value. A declared-but-empty custom property blocks the fallback:

/* Broken pattern */
--_bg: ;   /* defined but empty */
background: var(--_bg, var(--pattern-accent));  /* fallback never used */

This library uses the cascade instead:

background: var(--pattern-accent);              /* always present */
background: @match(...);                        /* empty → invalid → discarded */

Defaults always work. Overrides only apply when the phrase supplies a value.

4. Shared threshold

@define patterns(thr:0.65){`
  pattern(@use(thr): "…", `…`)
`}

@patterns(0.4)   /* caller sets sensitivity for the whole pack */

Threshold	Feel	Typical use
0.7–0.9	Strict	Short component names
0.4–0.5	Forgiving	Demo / longer role phrases
≤ 0.35	Very open	Easy collisions — keep descriptions unique

The demo uses 0.4 so paraphrases still hit without being reckless.

5. Design tokens in one place

@pattern-root()   /* writes --pattern-accent, radii, shadows, pads, … on :root */

Patterns reference tokens; callers override only what they need in the phrase.

6. Namespaced motion

Keyframes are prefixed (patternFadeInUp, patternShimmer, …) so they do not collide when you import other FSCSS modules.

What’s in the library

Cards — two-tone gradient (from / to / color), soft elevated surface (bg / radius)
Buttons — solid primary, surface, ghost outline (bg / color / border)
Hover — lift, scale, glow (lift / scale / glow)
Motion — fade-in-up, pulse, spin, shimmer + keyframes (duration)
Layout — centered max-width container, auto-fit grid, sticky translucent header, divider
Components — input + focus ring, pill badge, glass, tooltip, avatar + ring, skeleton, toggle track, progress track/fill, status alerts, tab underline, thin scrollbar
Text — single-line truncate, multiline clamp (lines)
A11y — :focus-visible ring, disabled muted state

Usage

Install

npm install fscss@1.2.4

Local import

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

@pattern-root()
@patterns(0.4)

.hero {
  vibrant two tone gradient card from: #121212 to: #676756 color: #fff
}

.btn-primary {
  solid filled primary button bg: #344466
}

.btn-primary {
  lift up on hover with stronger shadow lift: -2px
}

Compile (CLI or CI)

fscss demo.fscss demo.css

The repo includes a GitHub Action that recompiles demo.css on every .fscss push. The live demo serves that compiled file — no runtime required on the page.

Browser runtime (playgrounds)

<link type="fscss" href="./demo.fscss">
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.4/runtime.min.js" defer></script>

Design choices worth knowing

Descriptions are stable contracts. Change tokens freely; do not bake hex values into the match text.
One match group per concern. Keep regexes readable and 1.2.4-safe.
Defaults first, overrides second. That is the only reliable way to survive failed matches today.
Project-specific patterns belong in your own module. This pack is for roles many apps share.

Contribute

PRs welcome. Prefer:

Role-based, lexically distinct descriptions
Cascade defaults + simple @match
Namespaced pattern* keyframes
A short note in the PR with example phrases and the CSS they produce

See CONTRIBUTING.md.

Links

Write the role. Optionally pass the values in the same line. Get real CSS.

How to Use st-core.fscss with Svelte (Compiled)

FSCSS — Mon, 21 Sep 2026 11:00:57 +0000

st-core.fscss draws charts with pure CSS, clip-path polygons plus custom properties, no JS chart library, no SVG, no canvas. Svelte doesn't need to draw anything for it. It just needs to own the data and reactively set --st-p1, --st-p2, and so on whenever your series changes. Wanted to write up the actual integration because getting the responsibilities split correctly took me a minute the first time through.

Why compiled mode, not the runtime CDN

Svelte already has a build pipeline. Shipping the FSCSS runtime to a Svelte app just to expand a few chart mixins into static CSS is unnecessary work for the browser to do on every load. The runtime CDN script is fine for a CodePen or a quick static HTML demo, but for an actual Svelte or SvelteKit app you compile once at build time and import plain CSS.

Three layers, each with one job:

Layer	Job
FSCSS CLI	Expand `@st-chart-fill` / `@st-chart-line` into static CSS
Svelte	Reactive `data[]` → `--st-pN`
Browser CSS	Paint, plus optional `clip-path` transitions

Svelte state  →  style="--st-p1: 30%; --st-p2: 45%; …"
                      ↓
              compiled st-core.css
                      ↓
                 chart on screen

1. Write the FSCSS entry file

src/styles/st-core.fscss:

@import((*) from st-core@v2)

@st-root()

/* Length at compile time = number of polygon stops */
@arr chartData[0, 0, 0, 0, 0, 0, 0]

@st-chart-fill(.chart-fill, chartData)
@st-chart-line(.chart-line, chartData)

.chart {
  @st-chart-points(chartData)
  position: relative;
  width: 100%;
  height: 220px;
  background: var(--st-surface);
  border-radius: var(--st-radius-lg);
  overflow: hidden;
}

.chart-fill,
.chart-line {
  transition: clip-path 0.5s cubic-bezier(0.4, 0, 0.2, 1);
}

The zeros are placeholders, they only matter for their count. Svelte overwrites the real Y values through CSS variables at runtime. What you can't change without recompiling is the array's length — match it to your series (7 days of data → 7 entries).

2. Compile it as part of your build

npm install -D fscss@latest
npx fscss src/styles/st-core.fscss src/styles/st-core.css

Wire it into package.json so it runs automatically before every build:

{
  "scripts": {
    "build:st-core": "fscss src/styles/st-core.fscss src/styles/st-core.css",
    "prebuild": "npm run build:st-core"
  }
}

Then import the compiled CSS once, wherever makes sense for your app (root layout, app.css, or the chart's parent component):

import '../styles/st-core.css';

3. Map your data to `--st-pN`

Chart geometry in st-core is top-down, the same way CSS itself is. A high value needs to sit near 0%, not 100%. So every point gets inverted:

--st-pᵢ = (100 - humanValue) %

A score of 90 ends up 10% from the top, which is exactly where you'd expect it visually.

Here's a reusable Chart.svelte that does that mapping reactively, Svelte 4 style:

<script>
  /** @type {number[]} 0–100, higher = taller */
  export let data = [];
  export let height = '200px';
  export let color = '#9d7eff';

  $: cssVars = [
    ...data.map((value, index) => `--st-p${index + 1}: ${100 - value}%`),
    `--st-accent: ${color}`,
    `height: ${height}`
  ].join('; ');
</script>

<div class="chart" style={cssVars}>
  <div class="chart-fill"></div>
  <div class="chart-line"></div>
</div>

And the Svelte 5 version, using $props / $derived instead of the old export-let / reactive-statement pattern:

<script>
  let { data = [], height = '200px', color = '#9d7eff' } = $props();

  let cssVars = $derived(
    [
      ...data.map((value, index) => `--st-p${index + 1}: ${100 - value}%`),
      `--st-accent: ${color}`,
      `height: ${height}`
    ].join('; ')
  );
</script>

<div class="chart" style={cssVars}>
  <div class="chart-fill"></div>
  <div class="chart-line"></div>
</div>

Both do the exact same job, just with whichever reactivity API your Svelte version uses.

4. Use it like any other component

<script>
  import './styles/st-core.css';
  import Chart from './lib/Chart.svelte';

  let weekly = [45, 70, 30, 90, 60, 80, 50];

  function randomize() {
    weekly = Array.from({ length: 7 }, () => Math.floor(Math.random() * 80) + 10);
  }
</script>

<Chart data={weekly} color="#4fffb0" height="250px" />

<!-- Svelte 4 -->
<button type="button" on:click={randomize}>Randomize</button>

<!-- Svelte 5 -->
<!-- <button type="button" onclick={randomize}>Randomize</button> -->

Reassigning weekly recomputes cssVars, the browser applies the new custom properties, and the compiled CSS's clip-path transition animates the shape change. No chart library re-rendering, no SVG path recalculation, no manual DOM diffing on your end.

Fixed length vs changing length

Because geometry is baked in at compile time, the array length is the one thing you can't change on the fly:

Situation	What to do
Always exactly N points	Compile `@arr chartData` with N zeros, always pass exactly N values from Svelte
Length varies, up to a max of M	Compile M zeros, then `data.slice(0, M)` and pad shorter series with `0`

If you compile a template expecting 5 points and hand it 8 values from Svelte, the extra --st-p6, --st-p7, --st-p8 have nowhere to go, there's no polygon stop for them until you recompile with a longer array.

What not to do in production

<!-- Fine for a demo, avoid as your only path in a real Svelte app -->
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.3/runtime.min.js"></script>

Runtime mode is for CodePen and quick static HTML, not for a build pipeline that already exists. See the plain HTML integration sample if that's what you actually want.

The mental model, condensed

@st-chart-points, fill, and line define the structure and only ever read --st-p*.
Svelte's only job is to replace those variables when the data changes.
transition: clip-path gives you motion for free, no animation library needed.

Nothing here is Svelte-specific past step 3, the same pattern maps directly to Vue, React, or vanilla JS, only the reactivity layer changes. Contributions for other frameworks welcome under integration/.

Repo: github.com/fscss-ttr/st-core.fscss
Svelte sample: integration/svelte

Compile the chart. React to the data. Let CSS paint.

Pure CSS Charts? Yes, Really. Introducing st-core.fscss v2

FSCSS — Sat, 19 Sep 2026 19:10:33 +0000

If you've ever pulled in heavy libraries just to render a simple line chart, you know the drill: a few hundred KB of JavaScript, a canvas or SVG element, and a hydration step before anything even shows up on screen. For a lot of dashboards, that's massive overkill.

st-core.fscss takes a different approach. It's a CSS-only visualization system built on FSCSS that renders area charts, multi-line charts, and stat dashboards using nothing but clip-path: polygon() and CSS custom properties. No canvas. No SVG. No chart library shipping down the wire.

Here's how it works, and how to build real charts with it.

The Core Idea

Every chart in st-core is really just a polygon. Give the mixin an array of data points, and it:

Spaces the points evenly across the chart width (0% to 100%, based on array length)
Normalizes each value into a Y-position
Generates a clip-path: polygon() that traces the line (or fills the area beneath it)

@arr myData[50, 10, 97, 35, 66, 50, 80, 54, 70, 60]

@st-chart-fill(.chart-fill, myData)
@st-chart-line(.chart-line, myData)

That's the whole rendering pipeline. The array can be any length: 5 points, 50 points, doesn't matter.

Getting It Running

For Testing - Drop the runtime in your <head>:

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

Then import the module inside your <style> block:

@import((*) from st-core@v2)

Prefer a build step for production? The CLI compiles .fscss file straight to production CSS:

npm install -g fscss@latest
fscss input.fscss output.css

Vscode Extention for syntax highlights and auto-compile: FSCSS Support

A Basic Area Chart

<style>
@import((*) from st-core@v2)

@st-root()

@arr myData[20, 45, 28, 80, 65, 90, 40]

@st-chart-fill(.chart-fill, myData)
@st-chart-line(.chart-line, myData)

.chart {
  @st-chart-points(myData)
  position: relative;
  height: 200px;
  width: 100%;
  max-width: 400px;
  background: var(--st-surface);
  border-radius: 16px;
}
</style>

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

Two things worth calling out about how this splits responsibilities:

@st-chart-fill / @st-chart-line declare the renderer for a selector. The array argument just tells it how many points to expect.
@st-chart-points(myData) is what actually writes the --st-p1 through --st-p{n} values onto an element. Any child that doesn't call it inherits from the nearest ancestor that did — which is exactly what makes the multi-series case below work cleanly.

Multi-Line, Multi-Area Charts

This is where the point-inheritance model pays off. Each series gets its own renderer and its own explicit @st-chart-points call, so nothing bleeds into another series by accident:

@arr seriesA[30, 50, 75, 40, 85, 60]
@arr seriesB[10, 25, 45, 20, 55, 30]

@st-chart-fill(.fill-a, seriesA)
@st-chart-line(.line-a, seriesA)

@st-chart-fill(.fill-b, seriesB)
@st-chart-line(.line-b, seriesB)

.chart {
  @st-chart-points(seriesA)
  position: relative;
  height: 220px;
  width: 100%;
  background: var(--st-bg);
}

.fill-a {
  @st-chart-points(seriesA)
  opacity: 0.6;
  --st-accent: #9d7eff;
}
.line-a {
  @st-chart-points(seriesA)
  --st-accent: #9d7eff;
}

/* .fill-b / .line-b MUST set their own points, otherwise they'd
   silently inherit .chart's seriesA values */
.fill-b {
  @st-chart-points(seriesB)
  opacity: 0.3;
  --st-accent: #4fffb0;
}
.line-b {
  @st-chart-points(seriesB)
  --st-accent: #4fffb0;
}

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

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

Stack as many series as you want this way. Each one is independently opaque, colored, and pointed at its own array.

Custom Data Points and Markers

For a single highlighted marker (a peak, a tooltip anchor), use @st-chart-dot directly:

/* selector, x%, y%, size */
@st-chart-dot(.chart-dot, 70, 60, 12px)

To mark every point in a dataset automatically:

/* Generates .dot-1, .dot-2 ... .dot-N */
@st-chart-dots(.dot-, myData, 8px)

Combine that with @st-chart-grid(.chart-grid, rows, cols) and the axis wrappers @st-chart-axis-x / @st-chart-axis-y, and you've got a fully annotated chart with zero JS.

Making It Interactive Anyway

Pure CSS rendering doesn't mean the data has to be static. Updating a chart at runtime is just a matter of rewriting the --st-p{n} variables:

const chartLine = document.querySelector(".chart-line");
const normalize = (n) => (100 - n) + '%';

function updatePoints(pointsArray) {
  const cssVars = pointsArray
    .map((v, i) => `--st-p${i + 1}: ${normalize(v)};`)
    .join(' ');

  chartLine.style.cssText = cssVars;
}

updatePoints([50, 20, 85, 40, 95]);

Pair that with a transition: clip-path 0.6s cubic-bezier(0.4, 0, 0.2, 1); on .chart-fill / .chart-line, and dataset changes animate smoothly through the browser's compositor, without touching layout or paint.

Why This Matters

Zero hydration. The chart is visible the instant CSS parses. No JS has to boot before you see data.
Tiny footprint. The compiled output is shapes and custom properties, around 0.8kb minified.
GPU-accelerated updates. Because everything animates through clip-path and CSS variables, transitions run on the compositor thread instead of the main thread.

If you're building something where every kilobyte of JS matters (embedded widgets, low-power devices, SEO-sensitive pages), st-core gets you real, responsive charts without the usual charting-library tax.

st-core.fscss is MIT licensed and built on FSCSS

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

deepspace.fscss: a CSS planet in a box

FSCSS — Thu, 17 Sep 2026 22:12:06 +0000

A small FSCSS module that draws a deep-space scene: starfield, soft rays, atmosphere, rotating planet, and an orbiting moon. CSS (and FSCSS to package it).

Why a module?

The scene is easy to paste once and painful to keep consistent across pages. deepspace.fscss turns it into four helpers:

Helper	Role
`@deepspace-root()`	Tokens (size, glow, background)
`@deepspace-size(planet)`	Scale planet / system / moon together
`@deepspace(sel)`	Bind the scene to a host (default `body`)
`@deepspace-as-body()`	Full-viewport body reset when you want the page itself to be the stage

Important detail: the host is scoped. Use @deepspace(.scene) and overflow, stars, and motion stay inside that element. The rest of the page is untouched.

Contained demo

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

@import((*) from deepspace)

@deepspace-root()
@deepspace(.scene)
:root {
  @deepspace-size(200px)
}

body {
  margin: 0;
  min-height: 100vh;
  display: grid;
  place-items: center;
  background: #111;
  font-family: system-ui, sans-serif;
  color: #ccc;
}
main { width: min(420px, 92vw); }
h1 { font-size: 1rem; margin: 0 0 12px; font-weight: 600; }
.scene {
  height: 380px;
  border-radius: 16px;
  border: 1px solid rgba(255, 255, 255, 0.08);
}
p {
  font-size: 13px;
  color: #888;
  margin: 12px 0 0;
}

<main>
  <h1>deepspace.fscss — contained</h1>
  <div class="scene">
    <div class="ds-rays"></div>
    <div class="ds-planet-system">
      <div class="ds-atmosphere"></div>
      <div class="ds-planet"></div>
      <div class="ds-moon-orbit"><div class="ds-moon"></div></div>
    </div>
    <div class="ds-title">Deep Space</div>
  </div>
  <p>Overflow stays inside <code>.scene</code></p>
</main>

Markup classes: ds-rays, ds-planet-system, ds-atmosphere, ds-planet, ds-moon-orbit, ds-moon, ds-title.

Live preview

Fork from the template:

codepen.io/editor/pen?template=01a0b135-563b-7138-a185-260878cab5fb

Full page (optional)

When the scene should own the viewport:

@deepspace-root()
@deepspace-as-body()
@deepspace(body)

Put the same ds-* children on body (or nest them as in the sample).

Tokens

Defaults from @deepspace-root() — override anytime:

--ds-planet, --ds-system, --ds-moon
--ds-glow, --ds-bg-top, --ds-bg-bottom, --ds-title

Or scale in one call: @deepspace-size(180px).

Requirements

FSCSS ≥ 1.2.1 (runtime or CLI)
Import via deepspace / from deepspace

CSS art stays maintainable when it’s a module with a host selector, not a one-off paste on body.

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

Charts.css vs ProvChart vs FSCSS (st-core): three ways to chart without a JS chart library

FSCSS — Tue, 15 Sep 2026 18:25:11 +0000

JavaScript chart libraries are powerful, and heavy. For many pages you only need a trend, a bar comparison, or a simple gauge. Shipping 40-150 KB of chart runtime (plus hydration) is optional, not inevitable.

Three open approaches solve "show the data" without a client chart engine. They are not drop-in replacements for each other. They target different workflows.

The shared idea

All three keep visualization close to the browser's normal layout and paint path:

less main-thread chart code on first load
markup or CSS that crawlers and simple clients can see without executing a chart bundle
a clearer story for Core Web Vitals on content and marketing surfaces

How you author the chart is where they diverge.

Charts.css: tables first

Charts.css styles semantic HTML <table> markup. Classes and CSS variables turn rows and cells into bars, lines, and related views.

Best when

Accessibility is non-negotiable (e.g. WCAG-minded reports): the underlying table remains real data for screen readers
Marketing pages, blogs, CMS content, public reports
Static sites (Astro, Eleventy, Jekyll) where the chart is content, not an app shell

Workflow: write or generate a table, apply Charts.css classes, tune with CSS variables.

If your source of truth is already tabular and you care about semantics first, this is the natural fit.

ProvChart: data in, markup out

ProvChart treats charts as compile output: JSON (or a builder) becomes scoped HTML + CSS, or SVG for README/docs. Paint does not require a chart-library runtime. An optional small runtime can add tooltips later; the chart should still be visible without it.

Best when

Performance-sensitive pages (SSR, Jamstack widgets, mobile / low bandwidth)
Backend or CI owns the numbers; the page only injects markup
E-commerce or product surfaces where third-party chart scripts are a risk on the path to purchase
Agents/CI: API or MCP generates HTML/CSS or SVG from metrics

Workflow: metrics go to API or builder, then inject css + html (or commit .svg).

If your source of truth is JSON from a server or pipeline, and first paint matters more than an interactive analytics canvas, this fits.

FSCSS / st-core: charts as a CSS design layer

st-core.fscss lives in the FSCSS world: you describe chart structure in .fscss, and it compiles toward native CSS (custom properties, clip-path, grids, etc.).

Best when

Design systems and shared UI kits across React, Vue, Svelte, or plain HTML
Utility-first teams that want axes, fills, and grids as layout primitives
Fine control over geometry in CSS (including modern layout features) without a canvas API

Workflow: author in FSCSS, compile, ship CSS (+ light markup), same as the rest of the design system.

If charts are components in a design language, not one-off API responses, st-core is aimed at you.

Side-by-side

Focus	Charts.css	ProvChart	FSCSS (st-core)
Data enters as	HTML `<table>`	JSON / API properties	`.fscss` + CSS utilities
Strength	Accessibility & readable structure	Load speed & zero chart hydration	Custom visual systems
Feels like	Content + CSS framework	Compile step / service	Design-token / compiler layer

How to choose

Report or article with real tables -> Charts.css
Product page or dashboard strip fed by an API -> ProvChart
Multi-app design system, CSS-first components -> st-core / FSCSS

Many orgs use more than one: tables in the docs site, compiled API charts in the app header, st-core tokens in the component library.

What none of these replace

Brushing, crossfiltering, streaming ticks, and deep drill-down still favor a dedicated JS (or WebGL) library, on the routes that earn that cost. The win is defaulting content and KPI chrome to CSS-native pipelines so the heavy toolkit stays optional.

Links

Pick the workflow that matches how your data already lives, table, JSON, or design system, not the logo with the longest feature list.

Composition-First Styling with FSCSS

FSCSS — Mon, 14 Sep 2026 08:40:29 +0000

FSCSS is built around a modular, composition-first model. It doesn’t try to be a rigid UI framework. Instead it treats styling as reusable style units and design tokens that compile to standard CSS.

You get clear structure and encapsulation without a heavy JavaScript runtime or a complex build pipeline.

Composition over frameworks

Most tools push you toward components that own markup, state, and styles together. FSCSS stays in the style layer:

Tokens live on :root (or a scoped root define)
Shapes are @define helpers that accept a selector
Pages import only the helpers they need

@import((progress-root, circle-progress) from circle-progress)

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

That compiles to plain CSS. No runtime component tree—just styles you can combine the same way you combine utility classes, but with real parameters and shared tokens.

Modules like circle-progress, form, and st-core follow the same pattern: one root for tokens, namespaced defines, selective import.

Shorthand property multiplexing

To cut repetition, FSCSS supports arithmetic-style shorthand that expands to multiple properties at compile time.

Example — set width and height in one go:

%2(width, height [: 100px;])

At compile time that becomes identical declarations on both properties. Same idea scales to padding axes, gaps, and other paired values when you want symmetry without typing the same length twice.

See more patterns in the examples and the repo.

Keyframe and array automation

A large part of FSCSS is removing hand-written repetition for motion and variants.

Native-feeling structures:

@arr — declare lists of values
count() / index arrays — drive N steps
rpt() — repeat a fragment (e.g. nested selectors, staggered delays)

You can generate staggered animations, stepped color stops, or nested layout selectors without copy-pasting keyframe blocks or selector chains.

@arr levels[count(4)]

That’s the same idea as the nested-loop guide: one loop, many selectors.

Companion to modern CSS—not a replacement

FSCSS is intentionally a lightweight pre-compilation layer. It doesn’t hide the platform.

It works alongside:

Container queries
:has()
Anchor positioning
color-mix(), conic-gradient, masks, clip-path

You author shorter, structured source; the output is readable CSS that uses what browsers already do well. Ship via:

Mode	When
CDN runtime (`runtime.js` / `esm.js`)	Prototyping, demos
CLI (`fscss in.fscss out.css`)	Production, zero runtime

Mental model

Compose modules and defines, don’t inherit a framework
Multiplex repeated dimensions with shorthand where it helps
Automate lists and motion with methods like @arr
Emit standard CSS that plays with modern selectors and layout

FSCSS — figured shorthand, plain CSS output.

FSCSS – Lightweight CSS Preprocessor | Figured Shorthand CSS

Build faster with FSCSS. A powerful shorthand CSS system designed for scalable and efficient frontend styling.

fscss.devtem.org

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 v1.2.0 lets you write mixins directly in `style="..."` — here's why that's a bigger deal than it sounds

FSCSS — Fri, 04 Sep 2026 23:35:47 +0000

Up until v1.2.0, FSCSS syntax fully resolved inside <style> blocks. Inline style attributes were mostly just... inline CSS, the regular kind.

That changed in v1.2.0. Boot now processes every element's style attribute the same way it processes a <style> block. Same compiler, same pipeline, same @define mixins, same arrays. The practical result: you can call a mixin straight from an attribute, and combined with the JS API, you can recompile it on the fly.

Here's what that looks like, and why it's more useful than "less typing."

The setup

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

<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>
<button style="@btn-style(#4f4f4f)">Search</button>

One @define block, declared once. Three buttons, each calling it with a different color. No repeated class names, no utility soup, no separate stylesheet just to vary one property per element. On boot, FSCSS walks every style attribute, runs it through the same compiler that processes <style> blocks, and writes the compiled CSS back in place.

Where it gets interesting: dynamic updates

Inline processing on its own is a nice shorthand. Paired with the JS API, it becomes something closer to a lightweight styling engine.

<button style="
@arr colors[#1E2783, #8C29B2, #C41348, #0098d0]
@btn-style(@arr.colors!.randint)
" onclick="update(this)">Click</button>

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

Click the button, and xfscss.process() recompiles @btn-style(@arr.colors!.randint) on demand, picking a fresh random color from the array each time. The style attribute gets swapped out, no rewritten CSS, no framework state, no manual color logic in JavaScript. FSCSS just runs again.

The part that trips: the array is still there

Once boot processes that button's style attribute, the visible result is just the compiled declarations. The @arr colors[...] line is gone from the DOM, cleaned up along with the rest of the FSCSS source.

But the array itself was registered during that processing pass, not just written to that one attribute. So it's still resolvable afterward. That's the whole reason the click handler above works: @arr.colors!.randint keeps returning a valid color long after the line that declared it has disappeared from the page.

It's a small detail, but it's what makes inline processing genuinely useful for interactivity rather than a one-shot trick.

module mixins work the same way

Since boot doesn't treat style attributes as a special case, anything you can call inside a <style> block, including mixins from imported modules, works inline too:

<div class="chart-line line-2" style="background: #E8A030; @st-chart-points(10, 20, 16, 15, 66, 50, 80, 54)"></div>

That's an st-core chart mixin, called from an inline attribute, resolving exactly as it would from a stylesheet.

runtime.js or esm.js?

If you want this working automatically, runtime.js is the right entry point. It boots, processes every <style> block and style attribute on the page, and still exposes xfscss globally so you can call process() yourself afterward, exactly like the click handler above.

esm.js is a better fit when you want the compiler as a tool rather than something running against a live page, an FSCSS-to-CSS conversion utility, or a custom pipeline that decides what gets processed and when. It never touches the DOM unless you call reboot(), run(), or process() yourself.

Try it

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

Resources:

API References fscss.devtem.org/api
Docs: fscss.devtem.org/docs
GitHub: github.com/Figsh/xfscss

Automated GitHub repo stats as SVG in the README

FSCSS — Sun, 30 Aug 2026 16:51:53 +0000

Most README “stats” badges are either fixed images or another third-party widget. I wanted something simpler: read the repo from GitHub’s API, turn the numbers into SVG files in the repo, embed them like any image.

That’s what ProvChart Repo Stats does.

What it writes

File	Content	Default chart
`docs/charts/repo-overview.svg`	Stars, forks, watchers, open issues	area (real counts)
`docs/charts/languages.svg`	Language share	hbar

No hand-maintained chart JSON for those two.

Setup

Add a repo secret PROVCHART_API_KEY (key from chart.devtem.org/dashboard).
Workflow:

name: Repo stats charts

on:
  schedule:
    - cron: "0 8 * * 0"
  workflow_dispatch:

permissions:
  contents: write

jobs:
  charts:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: fscss-ttr/provchart-repo-stats@v1.3
        with:
          api-key: ${{ secrets.PROVCHART_API_KEY }}
        env:
          PROVCHART_API_KEY: ${{ secrets.PROVCHART_API_KEY }}

      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "chore: update repo stats charts"
          file_pattern: "docs/charts/*.svg"

README:

![Overview](./docs/charts/repo-overview.svg)
![Languages](./docs/charts/languages.svg)

Run the workflow once (or wait for the schedule). The SVGs commit back; the README stays normal Markdown.

Defaults worth knowing

Overview uses real counts (not forced to 0–100).
Languages use share %.
You can switch types (overview-type, languages-type) if you prefer bars.

Charts are generated with ProvChart (generate-svg). Related: provchart-readme-action if you already have a .provchart/charts.json and want fixed sample charts instead of live repo metrics.

Feedback and issues: github.com/fscss-ttr/provchart-repo-stats.

How to ship interactive charts and still aim for 100 performance

FSCSS — Wed, 26 Aug 2026 11:57:55 +0000

Interactive charts and a perfect Lighthouse run often feel incompatible. The usual path is a 50–150 KB chart library, hydration, and a blank box until JavaScript finishes. You can still offer real visuals and light interaction without paying that tax on every page load.

This article is about a paint-first pipeline: compile data to HTML/CSS, let the browser draw on first paint, then add interaction as progressive enhancement.

The real performance problem

Core Web Vitals care about what blocks the main thread and what delays useful pixels.

Cost	Typical JS chart stack	Paint-first CSS charts
Download / parse	Chart library + adapters	No chart library for paint
First paint	Often after JS runs	Chart HTML/CSS in the first response
SEO / first crawl	Depends on hydration	Markup present immediately
Interaction	Built into the library	Optional small runtime

“100 performance” is never a guarantee—fonts, images, and third parties still matter—but removing chart-runtime JS from the critical path is one of the highest-leverage wins on dashboard-style pages.

Pipeline: compile → paint → enhance

1. Compile

Send JSON to a generator (build step or API). Example with ProvChart:

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: "area",
    series: [
      { name: "Traffic", color: "#4fd8c4", points: [30, 45, 40, 60, 55, 70, 65] },
      { name: "Signups", color: "#f0a860", points: [8, 12, 11, 18, 16, 22, 20] },
    ],
    axisX: ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
  }),
});

const { success, html, css, error } = await res.json();
if (!success) throw new Error(error);

You get scoped HTML + CSS (custom properties, clip-path, bars, gauges)—not a client chart framework.

2. Paint

Inject on the server or at the start of the page:

document.head.insertAdjacentHTML("beforeend", `<style>${css}</style>`);
document.getElementById("chart").innerHTML = html;

On first paint the chart is already geometry in CSS. No new Chart(ctx, …).

3. Enhance (optional)

Interaction does not have to ride in the same bundle as rendering.

ProvChart Runtime is a separate MIT script: tooltips, scroll reveal, legend focus. Charts work without it.

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

Pattern: render is free of chart-library JS; UX is progressive.

What “interactive” can mean without a heavy library

Need	Lightweight approach
Hover values	Runtime tooltips / CSS hits
Legend focus	Dim other series on legend hover
Live data	Rewrite CSS variables or re-call generate
README / docs	`generate-svg` → commit `.svg` (no client runtime)
Full brush/zoom/analytics	Reserve a JS library for that route only

Most marketing pages, pricing metrics, and ops KPI strips need the first column—not a full analytics suite.

Checklist toward a top performance score

No chart library on the critical path — generate HTML/CSS ahead of time or via API; inline or ship only scoped CSS.
Defer enhancement — defer / type="module" for runtime; charts remain visible if it fails.
Respect prefers-reduced-motion — skip transform theatre when users ask.
Keep images honest — LCP is often a hero image, not the chart; optimize that separately.
Don’t block on fonts — font-display: swap for display type.
Split the product — paint-first charts on public pages; heavy JS charts only behind “Analytics” where interaction earns the KB.
Accessibility — short text summary + optional table (accessible charts).

Static sites and agents

SSG: generate charts at build time; commit HTML/CSS or call the API in CI.
README: prefer SVG file embeds over giant data URIs (Markdown guide).
Agents: stable JSON in → markup out is easy for ChatGPT/Claude tool calls—no browser chart API required.

When you should still use a JS chart library

Brushing, zooming, streaming ticks
Dozens of coordinated views
Exotic types your CSS engine doesn’t cover

Use them deliberately, on routes that justify the cost—not as the default for every sparkline.

Quick start

Build or API-generate a chart → inject html + css.
Confirm the chart shows with JS disabled (enhancement only).
Add runtime only if you want tooltips/motion.
Re-run Lighthouse on mobile; watch JS execution time and LCP.

Docs: chart.devtem.org/docs

Gallery: chart.devtem.org/gallery

Runtime: github.com/fscss-ttr/provchart-runtime

Maximize the visual by maximizing what the browser already paints. Compile data to CSS, ship interaction as an optional layer, and keep heavy chart runtimes off pages that don’t need them. That’s how interactive-looking charts stay compatible with serious performance budgets.

Embed Charts in Markdown Without Chart.js: SVG, Data URIs, and What Actually Works

FSCSS — Mon, 24 Aug 2026 11:08:20 +0000

Markdown is great until you want a real chart in a README or docs site. Most people reach for a screenshot, a hosted PNG, or a heavy client library. ProvChart takes another path: POST /api/v1/generate-svg returns a self-contained SVG (and optional data URI) from your data—no js on the page, no image CDN required.

This article covers what different Markdown platforms allow, practical embed patterns, and when pure SVG is the better default.

The idea

Send series data to ProvChart’s SVG endpoint.
Get back:
- svg — full <svg xmlns="...">...</svg> string
- dataUri — data:image/svg+xml;base64,...
Embed with whatever your platform supports.

Platform reality: not every Markdown engine is equal

Approach	GitHub README	Many static docs	Personal / controlled MD	Notes
Data URI `![](data:image/svg+xml;...)`	Often fragile	Sometimes OK	Often OK	Long base64 can break or get sanitized
`<img src="data:...">`	Limited	Varies	Often OK	Same length / sanitize issues
File `![](./chart.svg)`	✅ Reliable	✅ Reliable	✅ Best default	Commit the SVG; no key in the repo
Inline `<svg>`	❌ Usually stripped	Sometimes	✅ If HTML allowed	Great for MDX / some SSGs
Raster PNG/WebP	✅	✅	✅	Use only if the host blocks SVG

Takeaway: Prefer a committed .svg file for GitHub and public docs. Use data URIs for quick demos. Use inline SVG only where the engine allows raw HTML (MDX, some wikis, your own site).

Pattern 1 — Generate SVG (API)

curl -s -X POST "https://provchart-api.devtem.org/api/v1/generate-svg" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{
    "type": "line",
    "series": [
      { "name": "Stars", "color": "#8b7bff", "points": [12, 18, 25, 40, 55] }
    ],
    "axisX": ["Jan", "Feb", "Mar", "Apr", "May"],
    "width": 640,
    "height": 280
  }'

Response shape:

{
  "success": true,
  "svg": "<svg xmlns=\"http://www.w3.org/2000/svg\" ...>...</svg>",
  "dataUri": "data:image/svg+xml;base64,..."
}

Keep the key in CI secrets.

Pattern 2 — Embed options

A. Image from file (recommended for README)

![Stars over time](./docs/charts/stars.svg)

Save the svg field from the API into that path and commit it.

B. Data URI (quick, not always portable)

![Stars over time](data:image/svg+xml;base64,AAAA...)

If the preview is blank, the host likely truncated or blocked the URI—switch to a file.

C. Inline SVG (when HTML is allowed)

<!-- MDX / some static generators -->
<div>
  <!-- paste the svg string from the API -->
</div>

GitHub README will generally not render arbitrary inline SVG.

D. Raster only if you must

If a platform blocks SVG entirely, convert once in your pipeline (e.g. local tool) and commit PNG. That’s a fallback—not the default for your docs site, where SVG is usually better.

Advantages of the SVG path

No chart runtime in the doc UI — readers don’t download Chart.js to see a trend.
No third-party image host — nothing uploaded to a random CDN for a badge.
Sharp at any zoom — useful for docs and retina displays.
Same data model as HTML charts — type, series, axisX match ProvChart’s generate API.
CI-friendly — regenerate docs/charts/*.svg when metrics change; commit the artifact.
Fits the “pipeline” story — compile data → paint geometry; for Markdown the paint target is SVG instead of CSS-in-page.

When pure SVG is the better choice

Personal knowledge bases, Notion-export-style vaults, and static doc sites you control
GitHub/GitLab asset charts (versioned next to the repo)
Design systems / architecture READMEs that should stay dependency-light
Agent or cron jobs that refresh charts without opening a browser

Use HTML + CSS (/api/v1/generate) when the chart lives inside a web app where theme tokens and layout already use CSS.

Minimal Node helper (write a file)

import fs from "node:fs";

const res = await fetch("https://provchart-api.devtem.org/api/v1/generate-svg", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": process.env.PROVCHART_API_KEY,
  },
  body: JSON.stringify({
    type: "area",
    series: [{ name: "Views", color: "#4fd8c4", points: [10, 25, 40, 55, 48] }],
    axisX: ["Mon", "Tue", "Wed", "Thu", "Fri"],
    width: 640,
    height: 240,
  }),
});

const data = await res.json();
if (!data.success) throw new Error(data.error);
fs.writeFileSync("docs/charts/views.svg", data.svg);

Point Markdown at ./docs/charts/views.svg.

Troubleshooting

Symptom	Likely cause	Fix
Broken image in README	Data URI too long / blocked	Commit `.svg` + relative path
401	Bad or revoked key	New key in Dashboard → Developer API
429	Monthly limit	Upgrade plan or wait for reset
Empty graphic	Bad payload	Check `series[].points` and `axisX`

Links

SVG API: ProvChart docs – generate-svg
Guide: Charts in Markdown & docs
Pricing (quota): chart.devtem.org/pricing

Markdown support for data: URIs is inconsistent. For public README and most docs, generate SVG - save file - ![](./chart.svg). Use data URIs for experiments; use inline SVG only where your engine allows HTML. That’s how you get charts in docs.

DEV Community: FSCSS

How to build an analytics dashboard with FSCSS( st-core, circle-progress, and icon-mask)

Architecture

1. Project files

2. FSCSS — modules, tokens, chart

Imports and roots

Theme overrides

Minimal reset + shell

Revenue chart (st-core@v2)

Traffic pie (circle-progress)

Icons (icon-mask)

Responsive sidebar

3. HTML — structure only

4. JavaScript — behavior + data → variables

Mobile drawer

Chart ranges → --st-pN

Profile dropdown

5. Compile for production

6. Mental model

7. Next steps

Template & preview

patterns.fscss: Write CSS in Plain English

The idea

Feature overview

1. Role-based descriptions

2. @match — parameters in the phrase

3. Cascade fallbacks (no empty custom properties)

4. Shared threshold

5. Design tokens in one place

6. Namespaced motion

What’s in the library

Usage

Install

Local import

Compile (CLI or CI)

Browser runtime (playgrounds)

Design choices worth knowing

Contribute

Links

How to Use st-core.fscss with Svelte (Compiled)

Why compiled mode, not the runtime CDN

1. Write the FSCSS entry file

2. Compile it as part of your build

3. Map your data to --st-pN

4. Use it like any other component

Fixed length vs changing length

What not to do in production

The mental model, condensed

Pure CSS Charts? Yes, Really. Introducing st-core.fscss v2

The Core Idea

Getting It Running

A Basic Area Chart

Multi-Line, Multi-Area Charts

Custom Data Points and Markers

Making It Interactive Anyway

Why This Matters

deepspace.fscss: a CSS planet in a box

Why a module?

Contained demo

Live preview

Full page (optional)

Tokens

Requirements

Charts.css vs ProvChart vs FSCSS (st-core): three ways to chart without a JS chart library

The shared idea

Charts.css: tables first

ProvChart: data in, markup out

FSCSS / st-core: charts as a CSS design layer

Side-by-side

How to choose

What none of these replace

Links

Composition-First Styling with FSCSS

Composition over frameworks

Shorthand property multiplexing

Keyframe and array automation

Companion to modern CSS—not a replacement

Mental model

FSCSS – Lightweight CSS Preprocessor | Figured Shorthand CSS

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

Chart ranges → `--st-pN`

2. `@match` — parameters in the phrase

3. Map your data to `--st-pN`