FSCSS is open source, built in the open, and free for anyone to use, extend, or pick apart. That's the whole point of it. Every release is meant to make it easier for other developers to build with, not harder. v1.2.0 is the clearest example of that yet.
What shipped
Previous versions of FSCSS scattered their browser-facing files across the package: /e/exec.js, /exec.js, /xfscss.js, /xfscss.min.js, and more. Depending on what you needed, you'd end up guessing which file was the right one to load.
v1.2.0 consolidates all of that into two public entry points:
<!-- Auto-run, for plain HTML pages -->
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>
// Manual control, for tooling and modules
import xfscss from "https://cdn.jsdelivr.net/npm/fscss@1.2.0/esm.js";
runtime.js auto-scans the page and compiles everything on load, <style> blocks, <link type="fscss"> sources, and now inline style attributes too. esm.js never auto-runs and never touches page loading, since it's meant for using FSCSS as a tool: an FSCSS-to-CSS converter, a build step, or any pipeline where you decide what gets processed and when.
Use one or the other. Never both.
Nothing breaks
This is the part worth repeating: the npm package and CLI are completely unchanged, and every method that worked in the 1.1.x line still works exactly the same way in 1.2.0. @define, @fun, @event, @arr, pattern(), all of it. The consolidation only touches the browser entry-point files. If you're compiling ahead of time with the CLI, this release changes nothing for you.
Inline styles now go through the full pipeline
This is the headline feature. From v1.2.0, style="..." attributes are compiled on boot the same way <style> blocks are:
<style>
@define btn-style(bg: #636EE7){
padding: 10px 20px;
color: color-mix(#dddddd, @use(bg));
background: @use(bg);
border: 2px solid;
border-radius: 25px;
font-weight: 700;
}
</style>
<button style="@btn-style(#1a2a4f)">Search</button>
<button style="@btn-style(#f00f00)">Search</button>
Combined with xfscss.process(), that means an inline mixin call can be recompiled at runtime and swapped straight back into the element, no rewritten CSS, no framework state:
const update = async (btn) => {
const newStyle = await xfscss.process("@btn-style(@arr.colors!.randint)");
btn.setAttribute("style", newStyle);
};
The full walkthrough of this: including a detail (method declared inline stay resolvable even after their declaration is cleaned out of the attribute), if you want to go deeper: FSCSS v1.2.0 lets you write mixins directly in style="...".
None of this is about adding complexity for its own sake. FSCSS exists to cut down on repetitive CSS and give developers capabilities plain CSS doesn't have natively, and every release should make that easier to reach for, not harder to keep up with. Two entry points instead of a pile of internal files. Full compatibility instead of a migration guide. A feature that makes the JS API and the language work together instead of sitting side by side.
Open source only stays useful if the people using it can trust an upgrade won't cost them a rewrite. That's the bar this release was held to.
try it
npm install fscss@latest
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>
Bug reports, feature requests, and pull requests are all welcome on GitHub