DEV Community: FSCSS

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.

Email Charts with the ProvChart API

FSCSS — Sun, 23 Aug 2026 10:41:23 +0000

Most chart libraries assume a browser that runs JavaScript. Email clients don't give you that. If you want a chart in a weekly digest, you need something that renders without a script tag, or a step that turns a chart into an image before it ever reaches an inbox.

That's the problem ProvChart's API is built for. It returns HTML and CSS, generated server-side, and you decide from there whether to rasterize it into a PNG or embed a tightly controlled snippet. This post walks through the flow, the chart types that actually work in a digest, and a handful of practical tips for running this in production.

Why email is different

The inbox never needs to see your API key or your chart library. It only needs a static image and a link back to the live dashboard. Everything else, the data pull, the payload mapping, the API call, happens on your server or in a worker, before the send.

The flow

Pull analytics for the period, from your API, warehouse, or database
Map the rows into a ProvChart payload (type, series, axisX, theme)
POST /api/v1/generate with your API key
Turn the returned html and css into a PNG (or store the snippet)
Embed the result in your email template with a CTA back to the dashboard

Mapping analytics to a payload

Keep a single mapper function so every report type shares the same shape:

function analyticsToPayload(report) {
  return {
    type: "line",
    series: [
      {
        name: "Revenue",
        color: "#8b7bff",
        points: report.revenueByDay.map(d => d.value)
      },
      {
        name: "Orders",
        color: "#4fd8c4",
        points: report.ordersByDay.map(d => d.value)
      }
    ],
    axisX: report.revenueByDay.map(d => d.label),
    theme: {
      bg: "#0c0a16",
      surface: "#1a1628",
      text: "#eae7f5",
      muted: "#837da0",
      grid: "#8b7bff",
      radius: "12px"
    }
  };
}

Swap the data source underneath it, but keep the function stable. Weekly, monthly, and alert emails all stay consistent this way.

Chart types that actually work in a digest

Use case	Type	Why
Trend over 7–30 days	`line` / `area`	Readable as a simple story
Channel or category mix	`bar`	Clear comparison
Goal or conversion	`gauge`	One number, high impact
Share of total	`stackedbar`	Good for mix breakdowns

Skip dense scatter plots or multi-combo charts in email. Save those for the product UI, where someone can actually zoom in and interact.

Ten things worth doing

Generate server-side. The send job or worker owns the API key, the payload, and the output. Never call the API from the client.
Prefer images for email clients. The reliable path is: analytics → API → html/css → headless render (Playwright or Puppeteer) → PNG → CDN → <img> in the template. This works across Gmail, Outlook, and Apple Mail.
Design for one glance. Each chart should answer one question: did revenue rise, which channel led. Cap it at one or two series and 7–14 data points. Put the headline number in the subject line or preheader.
Cache by payload hash. Identical type, series, labels, and theme should produce identical output. Cache the html/css or the PNG so repeat sends don't burn quota.
Check usage before bulk sends. Hit GET /api/v1/usage first. If remaining is low, drop the optional charts or fall back to number-only blocks rather than hitting MONTHLY_LIMIT_REACHED mid-campaign.
Theme for email, not the admin UI. Use higher contrast and a background that matches your template. A dedicated theme object for digests versus in-app charts goes a long way.
Always add a CTA. A simple "Full dashboard →" link under the chart. The email is the snapshot; the app is where people explore.
Keep one layout per digest type. Hero metric, one trend chart, one breakdown, a few bullets, then the CTA. Change the data, not the structure.
Validate before you generate. Empty series, non-numeric points, or oversized arrays waste generations. Enforce max points and required fields in the mapper itself.
Proxy the key. Production frontends shouldn't hold the secret key at all. Route browser requests through your own backend before they reach ProvChart.

A minimal server-side example

const payload = analyticsToPayload(weeklyReport);

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(payload)
});

const data = await res.json();
if (!data.success) throw new Error(data.error);

// Option A: rasterize data.html + data.css into a PNG, upload it, then <img src="...">
// Option B: store the snippet for a web version of the same report

Do / Don't

Generate server-side
Map analytics to a fixed payload shape
Cache by hash
Prefer line, bar, or gauge charts
Link back to the live dashboard

Don't

Call the API from the inbox
Build ad-hoc JSON for every send
Regenerate identical charts
Pack five dense series into a digest
Expect full interactivity in email

Next steps

Introduction to ProvChart — Charts Without the JavaScript Tax

FSCSS — Sat, 22 Aug 2026 08:28:32 +0000

Introduction to ProvChart

Most charting libraries ask you to ship 40–150 kb of JavaScript, wait for hydration, and hope crawlers eventually see the chart.

ProvChart takes a different path.

It turns your data into CSS custom properties. The browser paints the chart with native CSS (clip-path, gradients, and a few carefully chosen rules). The result is a chart that:

Loads with the first paint
Ships zero chart library to the page
Is fully visible to search engines on the first crawl
Can still be updated by changing CSS variables

No canvas. No SVG charting runtime. No “wait for JS.”

The idea in one sentence

Data → CSS variables → browser paints the shape.

You (or the API) compile points into variables like --p1, --p2, ….

A pure CSS structure uses those variables to draw lines, areas, bars, or gauges.

After that, the page doesn’t need a charting library at all.

What you get

Feature	Detail
Output	Self-contained HTML + CSS
Runtime on the page	None for the chart itself
Types	Line, area, bar, stacked bar, horizontal bar, scatter, combo, gauge
Themes	Dark, light, midnight, or fully custom
SEO	Chart markup is in the first HTML response
Updates	Change CSS variables (or regenerate) — no virtual DOM chart layer

There is also a Developer API: send JSON, get back { html, css }, inject into any page or pipeline.

Who it’s for

Teams that care about LCP, TTI, and bundle size
Marketing and docs sites that need crawlable charts
Static or mostly-static pages that still need real data viz
Backends that want to generate charts for emails, reports, or static builds without shipping a client-side chart library

If you need heavy interaction, streaming of thousands of points, or complex JS-driven animations, a traditional library may still fit better. ProvChart optimizes for performance, simplicity, and SEO.

Quick taste (API)

const res = await fetch("https://provchart-api.devtem.org/api/v1/generate", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": "YOUR_API_KEY"
  },
  body: JSON.stringify({
    type: "line",
    series: [
      { name: "Revenue", color: "#8b7bff", points: [20, 35, 48, 66] },
      { name: "Users", color: "#4fd8c4", points: [12, 28, 41, 55] }
    ],
    axisX: ["Jan", "Feb", "Mar", "Apr"]
  })
});

const data = await res.json();
// data.html + data.css → inject into the page

Free accounts get a few test generations so you can try the full flow.

Pro and Business unlock higher monthly limits for production use.

Open source core + hosted product

Rendering core: st-core.fscss (MIT) — pure CSS chart primitives for the FSCSS ecosystem
Hosted product: ProvChart — visual builder, dashboard, Developer API, billing (by DevTemple)

You can use the open-source core on its own, or the hosted API when you want keys, limits, and multi-series generation without maintaining the engine yourself.

Try it

Link	What
chart.devtem.org	Product home
Get started	Free visual builder (no signup for single-series)
Docs	Core + Developer API
Pricing	Free / Pro / Business

What’s next from this org

We’ll publish short, practical posts on:

Building a small chart generator with the API
Using ProvChart in email digests (server-side → image/snapshot)
Performance and SEO notes vs typical JS chart stacks
Themes, multi-series patterns, and real dashboard layouts

If you care about charts that stay fast and crawlable, you’re in the right place.

ProvChart — charts without the JavaScript tax.

chart.devtem.org

Looking back at my 2024 article 😅

FSCSS — Sat, 22 Aug 2026 00:44:57 +0000

2024 FSCSS vs 2026 FSCSS — still moving, still light, still backward-compatible

Looking back at my 2024 article 😅

https://dev.to/figsh/my-rotate-animation-css-fscss-46b

2024 FSCSS vs 2026 FSCSS

Still moving with FSCSS 😕

Code written for v1.1.3 still runs fine on v1.1.26.

No breaking changes.

Backward compatibility is still a real thing here.

What was already there early:

Animation compact - since 1.1.0
Arrays - since 1.1.2
%n(), $variables, -* vendor prefixing… - since the unreleased days

What came later:

v1.1.24 - @define + selective @import
v1.1.25 – 1.1.26 - pattern() (write what you mean, let the compiler match it) - https://dev.to/fscss/pattern-in-fscss-write-what-you-mean-let-the-compiler-match-it-541m

The hardest recent release (and my favorite)

The real upgrade was the @import that can pull @define blocks and rename them on the fly:

@import((yourname as myname, brother as bro) from "/me.fscss")

@bro()
@myname()

Because it works directly with @define:

load - read - edit - paste…

Still light. Still pure CSS at the end.

Where everything lives

Docs - fscss.devtem.org
Learning hub - hub.devtem.org
npm - npmjs.com/package/fscss
One of the modules - github.com/fscss-ttr/st-core.fscss

A small note on the JavaScript journey

I’ve been simplifying some possibilities ❤️

Less noise. More direct paths.

Thank you to everyone who keeps sending heads ♥️❤️

I see you.

Still building.

Still light.

Still moving. 🎉

FSCSS tutorial Follow

Figured Shorthand Cascading Style Sheet

Build Pure CSS Charts from Your Backend with the ProvChart API

FSCSS — Thu, 20 Aug 2026 19:35:05 +0000

No chart libraries. No runtime. Just HTML + CSS.

If you’ve ever wanted charts that:

Load with the first paint
Are fully crawlable by search engines
Don’t ship a heavy JavaScript charting library
Can still be generated dynamically from your own data

…then you might like what ProvChart does.

ProvChart is a pure-CSS chart engine. Instead of rendering with Canvas or SVG + JavaScript, it compiles your data into CSS custom properties. The browser then paints the chart using clip-path and native CSS.

Today I’m sharing how to use the ProvChart Developer API so you can generate these charts from your own backend or frontend.

What You Get

You send JSON → you receive:

{
  "success": true,
  "html": "<div class=\"pc-...\">...</div>",
  "css": ".pc-... { ... }"
}

Drop the HTML and CSS into any page and the chart appears. No client-side chart library required.

Quick Example (Frontend)

Here’s a complete working example:

<div id="chart-container"></div>

<script type="module">
  try {
    const res = await fetch("https://provchart-api.devtem.org/api/v1/generate", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "X-API-Key": "YOUR_API_KEY"
      },
      body: JSON.stringify({
        type: "line",
        series: [
          { name: "Revenue", color: "#8b7bff", points: [20, 35, 48, 66] },
          { name: "Users", color: "#4fd8c4", points: [12, 28, 41, 55] }
        ],
        axisX: ["Jan", "Feb", "Mar", "Apr"]
      })
    });

    const data = await res.json();

    if (data.success) {
      // Inject the chart HTML
      document.getElementById("chart-container").innerHTML = data.html;

      // Inject the CSS
      document.querySelector("head").insertAdjacentHTML(
        "beforeend",
        `<style>${data.css}</style>`
      );
    } else {
      console.error("API Error:", data.error);
    }
  } catch (err) {
    console.error("Fetch Error:", err);
  }
</script>

That’s it. The chart is now on the page as pure HTML + CSS.

Supported Chart Types

Type	Description	Plan
`line`	Multi-series line chart	Free/Pro
`area`	Filled area chart	Pro
`bar`	Vertical bars (optionally stacked)	Free/Pro
`stackedbar`	Stacked vertical bars	Pro
`hbar`	Horizontal bars	Pro
`scatter`	Scatter plot with radius	Pro
`combo`	Mixed bar + line	Pro
`gauge`	Circular KPI gauge	Free/Pro

Authentication

You need an API key.

Go to chart.devtem.org/dashboard
Open the Developer API tab
Click Create key
Copy the key (it is shown only once)

Send it in the header:

X-API-Key: pc_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Authorization: Bearer pc_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Request Format

{
  "type": "line",
  "series": [
    {
      "name": "Revenue",
      "color": "#8b7bff",
      "points": [20, 35, 48, 66]
    }
  ],
  "axisX": ["Jan", "Feb", "Mar", "Apr"],
  "theme": "dark"          // optional: "dark" | "light" | "midnight"
}

Series object options

{
  "name": "Series name",
  "color": "#8b7bff",
  "points": [10, 20, 30],
  "type": "line",          // only for combo charts
  "stack": true,           // for stacked bars
  "radius": 6              // for scatter
}

Node.js Example

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: "Signups", color: "#4fd8c4", points: [12, 28, 35, 42, 58] }
    ],
    axisX: ["Mon", "Tue", "Wed", "Thu", "Fri"]
  })
});

const data = await res.json();

if (data.success) {
  // You can now store data.html + data.css
  // or inject them into a template
  console.log(data.html);
  console.log(data.css);
}

Checking Usage

curl https://provchart-api.devtem.org/api/v1/usage \
  -H "X-API-Key: YOUR_API_KEY"

Response:

{
  "plan": "pro",
  "used": 142,
  "limit": 500,
  "remaining": 358,
  "month": "2026-08"
}

Plans & Limits

Plan	Monthly Generations	Max Series
Free	0	—
Pro	500	12
Business	5,000	50
Enterprise	Custom	Custom

Why This Approach?

Most chart libraries work like this:

Ship a large JS library
Wait for JS to execute
Create DOM / Canvas / SVG
Re-render on every data change

ProvChart works like this:

Compile data → CSS variables
Browser paints with clip-path
Update = change CSS variables (native interpolation)

This gives you:

Zero chart library weight on the page
First-paint charts
Perfect SEO / crawlability
Very simple updates

Error Handling

The API returns clear error messages:

{
  "success": false,
  "error": "Monthly limit reached (500 generations). Upgrade your plan or wait until next month.",
  "code": "MONTHLY_LIMIT_REACHED",
  "used": 500,
  "limit": 500
}

Common codes:

INVALID_API_KEY
PLAN_REQUIRED
MONTHLY_LIMIT_REACHED

Try It

Free visual builder (no signup): chart.devtem.org/get-started
Full docs: chart.devtem.org/docs
Dashboard & API keys: chart.devtem.org/dashboard

The core rendering engine is open source (st-core.fscss). The hosted API + Pro features are provided for special use.

Would love to hear what you build with it.

Happy charting!

pattern() in FSCSS: Write What You Mean, Let the Compiler Match It

FSCSS — Tue, 18 Aug 2026 10:42:42 +0000

FSCSS v1.1.25 ships a new core method: pattern().

It's the first FSCSS feature that doesn't ask you to remember an exact name. Instead of calling @card() or @btn-primary(), you describe what you want in plain language, and FSCSS matches the closest pattern at compile time.

pattern(0.5: "Hello World Card", `
  border-radius: 12px;
  padding: 24px;
  background: linear-gradient(135deg, #667eea, #764ba2);
  color: #fff;
  box-shadow: 0 8px 24px rgba(0,0,0,0.25);
`)

.card {
  hello world card
}

Compiles to:

.card {
  border-radius: 12px;
  padding: 24px;
  background: linear-gradient(135deg, #667eea, #764ba2);
  color: #fff;
  box-shadow: 0 8px 24px rgba(0,0,0,0.25);
}

Notice .card doesn't call anything — it just contains a phrase close enough to "Hello World card" to trigger the match.

Why this exists

@define is precise but rigid. You call it by exact name, with exact arguments. That's great for a library you built yourself, but it breaks down in a few real situations:

Design handoffs. A designer or junior dev writes dark card with rounded corners inside a rule instead of hunting through your define library for the right call signature.
AI-generated markup. Tools that generate FSCSS from natural-language prompts can emit descriptive phrases instead of needing to know your exact mixin names.
Fast prototyping. You don't always remember what you named something six months ago. pattern() lets close-enough phrasing still resolve correctly.

pattern() doesn't replace other variable methods — it sits next to it, for cases where flexibility matters more than precision.

The syntax

pattern(threshold: "description", `
  css to inject
`)

threshold — a number from 0 to 1. The minimum similarity score a phrase must reach to trigger this pattern. Omit it and it defaults to 1 (near-exact match only).
description — the plain-language phrase you're matching against.
css — what gets injected when a phrase matches. Use backticks so the CSS can freely contain single or double quotes.

Threshold uses a colon, deliberately — 0.5: reads as a labeled parameter, distinct from a plain comma-separated argument. It's there so the number's purpose is visually obvious to anyone reading your stylesheet.

How matching works

Every phrase in your code gets compared against every pattern description using similarity scoring (Dice coefficient, if you're curious — it compares word overlap between the phrase and the description). The pattern with the highest score that also clears its own threshold wins.

That means:

pattern(0.8: "dark background and light color", `
  background: #212121;
  color: #ffffff;
`)

.chip {
  style dark background and light color
}

.tooltip {
  dark background light color
}

Both .chip and .tooltip resolve to the same CSS, even though neither phrase matches the description word-for-word. That's the point — you're not looking up a name, you're describing an outcome.

Tuning the threshold

High threshold (0.8–1) → strict. Good for short, generic descriptions where you don't want accidental matches ("button" alone would be too easy to trigger by accident).
Low threshold (0.4–0.6) → forgiving. Good for longer, more specific descriptions where a few words might vary but the intent is clearly the same.

If two patterns could plausibly match the same phrase, the highest-scoring one wins — so keep descriptions distinct from each other, especially at lower thresholds.

Property patterns vs. block patterns

Same split as @define:

Property patterns inject a group of declarations inside a rule:

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

.btn {
  rounded primary button
}

Block patterns inject full structures — keyframes, media queries, whole at-rules — and can stand alone outside any selector:

pattern(0.7: "animated keyframe for spin", `
  @keyframes spin {
    0% { transform: rotate(0); }
    100% { transform: rotate(360deg); }
  }
`)

an Animated keyframe for spin

Content injection example

Because the CSS argument is just a string, pattern() isn't limited to properties — it can inject anything valid at that point in your stylesheet, including pseudo-element content:

pattern(0.9: "hello world heading", `h1:before{content: 'Hello World';}`)

.title {
  hello world heading
}

What's shipped in v1.1.25

CDN
API
CLI
VSCode Extention

Try it

pattern() is live now on v1.1.25

Docs: fscss.devtem.org/pattern

customizable.fscss

FSCSS — Sat, 15 Aug 2026 12:37:09 +0000

CSS Page-styling system for the FSCSS ecosystem. It provides the components most sites need repeatedly — navigation, hero sections, feature grids, call-to-action banners, footers, 404 pages, and long-form article typography — as a single module that can be imported in full or in part, then restyled per page through CSS custom properties.

License: MIT

Repository: https://github.com/fscss-ttr/customizable.fscss

FSCSS v1.1.24 or later

I made a decision cube you rotate by scrolling — pure CSS, one JS listener

FSCSS — Sat, 08 Aug 2026 08:56:32 +0000

Can't decide? Scroll a cube until it lands on an answer.

This is a small demo built on cube.fscss, the 3D cube module — but instead of a CSS @keyframes spin, this one's rotation is driven entirely by scroll position. One scroll event listener, two lines of transform math, zero animation libraries.

<script src="//cdn.jsdelivr.net/npm/fscss@1.1.24/exec.min.js" async></script>

<style>
@import((*) from cube)

body{
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  overflow-x: hidden;
  background: #06f;
}

@cube-root(root)
@cube-wrapper(.cube)
@cube-face(.cube div)
@cube-face-left(.cube .f1)
@cube-face-right(.cube .f2)
@cube-face-top(.cube .f3)
@cube-face-bottom(.cube .f4)
@cube-face-front(.cube .f5)
@cube-face-back(.cube .f6)

.cube{
  @cube-size(200px)
  position: sticky;
  %4(right, left, top, bottom [: 50px;])
  transition: all 0.3s ease;
}

.container{
  overflow: scroll;
  position: relative;
  width: 300px;
  height: 300px;
}
.container .empty{
  width: 7020px;
  height: 5910px;
}
</style>

<div class="container">
  <div class="cube">
    <div class="f1">Yes</div>
    <div class="f2">No</div>
    <div class="f3">Maybe</div>
    <div class="f4">True</div>
    <div class="f5">False</div>
    <div class="f6">None</div>
  </div>
  <div class="empty"></div>
</div>

<script>
  const container = document.querySelector(".container");
  const cube = document.querySelector(".cube");

  container.addEventListener("scroll", e => {
    cube.style.transform = `rotateX(${e.target.scrollTop / 2}deg) rotateY(-${e.target.scrollLeft / 2}deg)`;
  });
</script>

How it works

The trick is a scrollable container way bigger than the cube itself — a 7020px × 5910px empty div gives the browser somewhere to actually scroll to. .cube is position: sticky, so it stays pinned in the viewport while the container scrolls underneath it, and one listener reads scrollTop/scrollLeft on every scroll tick and maps them straight to rotateX/rotateY on the cube:

cube.style.transform = `rotateX(${scrollTop / 2}deg) rotateY(-${scrollLeft / 2}deg)`;

Divide by 2 to slow the rotation relative to scroll distance — tune that number to make it feel slower/faster. Everything else — face geometry, sizing, positioning — is cube.fscss doing what it already does; I just swapped a @keyframes animation for a JS-driven transform on the same element.

Why sticky + oversized container

I tried a few approaches before landing on this one:

IntersectionObserver — works, but overkill for something this simple and doesn't give you continuous fractional rotation, just enter/exit events.
scroll-timeline / CSS scroll-driven animations — the "correct" modern answer, but browser support is still patchy enough that I didn't want to gate the demo behind it.
Sticky + giant scroll track — the one above. Cheap, works everywhere position: sticky does, and the scroll listener is the only JS in the whole thing.

Try it

Swap the six words for anything — a yes/no/maybe decision cube, a mood picker, a "roll to reveal" card gimmick. The geometry mixins don't care what's inside each face.

@cube-face-left(.cube .f1)
@cube-face-right(.cube .f2)
@cube-face-top(.cube .f3)
@cube-face-bottom(.cube .f4)
@cube-face-front(.cube .f5)
@cube-face-back(.cube .f6)

Cube.fscss is open-source, repository: github.com/fscss-ttr/cube.fscss, MIT License

DevTemple: a marketplace for developers and designers to sell code, templates & assets

FSCSS — Wed, 15 Jul 2026 00:21:37 +0000

We built DevTemple (devtem.org) — a live digital marketplace where developers and designers sell code templates, UI kits, graphics, and other digital assets, with instant downloads for buyers.

Why We built it

I make and sell digital products myself, and kept hitting the same frustrations on other platforms — fees that don't make sense for smaller creators, no real visibility into earnings, and buyers having to trust a screenshot instead of actually seeing the thing work before paying.

DevTemple is my answer to that: a place built specifically for code/design assets, where sellers get a proper profile, real-time earnings and referral tracking, and buyers can preview a template live in the browser before they buy — not just look at static images.

How it works

Sellers create an account, and upload their products (templates, kits, graphics, snippets, etc.)
Buyers browse, preview live where available, and check out securely via Paystack
Live Preview runs the actual HTML/CSS/JS in-browser so buyers know exactly what they're getting
Referral program lets anyone earn commission (7%, or 10% for Pro members) by sharing links
Seller dashboard tracks earnings, subscribers, and withdrawals in one place — payouts go straight to your bank

Not trying to replace any other platform — it's its own thing, built around instant-download digital assets for the developer/designer crowd.

Will it help?

That's what I'm putting out there to find out. If you build things — templates, kits, snippets, assets — and want a place to sell them where buyers can actually try before they buy, I think it's worth checking out. And if you're buying, the live preview alone should save you from a few bad surprises.

Would genuinely appreciate people trying it out — as a seller or buyer — and telling me what's missing.

🔗 devtem.org

🔗 FAQ