What changed in 1.2.0

FSCSS is still a preprocessor: your .fscss files become standard CSS. In the browser you now choose one of two public entry points — never both on the same page.

Build Use when Auto-runs?
runtime.js / runtime.min.js Plain HTML pages, demos, quick prototypes Yes — scans <link type="fscss"> and <style>
esm.js Modules, tools, sandboxes, selective processing No — you call process() or reboot()
@import inside FSCSS (pulling one .fscss into another) is documented on the @import page. This page covers loading FSCSS from HTML / JavaScript.

HTML link + runtime

Drop-in: link your file and load runtime.min.js

ESM + process

Full control: import esm.js and call the API

exec() still works

Inject text or URL on demand via xfscss.exec

1.1.x methods kept

run, process, inline, assign, reboot, exec

Method 1: HTML link + runtime.js (recommended for pages)

Auto-scan and process

runtime.js

The simplest path. Load runtime.min.js; it finds every <link type="fscss"> (or type="text/fscss"), fetches them, processes all <style> elements, and handles inline style attributes.

1

Create your FSCSS file

style.fscss 
$primary: #2563eb;
$radius: 8px;

.btn {
  background: $primary;
  color: white;
  padding: 12px 24px;
  border-radius: $radius;
}
2

Link it and load the runtime

index.html 
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>FSCSS Example</title>

  <!-- Your FSCSS file -->
  <link type="fscss" href="styles/style.fscss">

  <!-- v1.2.0 runtime (auto-runs) -->
  <script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>
</head>
<body>
  <button class="btn">Themed button</button>
</body>
</html>
Tips:
  • Prefer type="fscss" (also accepts values containing fscss).
  • Use async or defer on the script tag.
  • The global xfscss object is still available if you need run() / process() later.

Method 2: ESM + process / reboot (full control)

Manual processing — tools, sandboxes, selective runs

esm.js

esm.js never auto-runs and does not touch a loader element. Import it and call the API when you are ready.

Process a string only

JavaScript (module) 
import xfscss from "https://cdn.jsdelivr.net/npm/fscss@1.2.0/esm.js";

const source = `
  $primary: #2563eb;
  .btn { background: $primary; color: white; }
`;

const css = await xfscss.process(source);
// inject css into a <style> tag or write to disk

Full page bootstrap (fetch links + process styles)

JavaScript (module) 
import xfscss from "https://cdn.jsdelivr.net/npm/fscss@1.2.0/esm.js";

// Same as runtime’s main path, but only when you call it
await xfscss.reboot();   // alias: xfscss.assign()
Use this pattern for live sandboxes, build tools, and any case where auto-running on load would be wrong. See the API reference for run, inline, process, assign, exec, and reboot.

Method 3: xfscss.exec() — inject text or URL on demand

Dynamic load with callbacks

exec()

Available on both builds (global from runtime, or from the default export of esm). Inject a string or fetch a URL, then process.

With runtime (global xfscss) 
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>
<script>
  // after the script has loaded
  xfscss.exec({
    type: "fromUrl",           // or "URL", "link", "external"
    content: "styles/theme.fscss",
    onSuccess: (styleEl) => console.log("Applied", styleEl),
    onError: (msg) => console.error(msg)
  });

  // or from a string
  xfscss.exec({
    type: "text",              // or "fscss", "auto", ...
    content: "$c: #e11d48; .alert { color: $c; }"
  });
</script>
With esm 
import xfscss from "https://cdn.jsdelivr.net/npm/fscss@1.2.0/esm.js";

xfscss.exec({
  type: "fromUrl",
  content: "https://example.com/theme.fscss",
  onSuccess: (el) => { /* ... */ },
  onError: (msg) => { /* ... */ }
});

Production: compile with the CLI

Zero runtime dependency

For production, prefer compiling ahead of time so the page ships plain CSS:

bash 
npm install -g fscss
fscss styles/style.fscss dist/style.css

Then link the compiled file as a normal stylesheet — no FSCSS runtime required on the page.

Which approach should you use?

runtime.js

Best for:

  • Simple HTML sites and demos
  • Prototyping without a bundler
  • Auto-scanning link + style tags

esm.js

Best for:

  • Sandboxes and live editors
  • Build tools / FSCSS→CSS converters
  • Processing only selected strings

CLI

Best for:

  • Production deploys
  • CI pipelines
  • Zero runtime weight
Do not load both runtime and esm on the same page unless you know why. Pick one entry point. All 1.1.x methods remain available on the xfscss object.
API Reference @import guide Documentation npm