LollipopCSS: a tiny CSS preprocessor for defining your own shortcuts

The typing problem LollipopCSS was written to remove

The README is unusually honest about its own motivation. SCSS already solves reusable values and reusable blocks, and the author says so directly: "SCSS can already do all of this. That's not the problem." The stated problem is keystroke count. Writing @mixin normalStyle and then @include normalStyle in every rule is more ceremony than the author wants, and color: var(--normal-red) is more characters than the author wants. LollipopCSS exists to shorten both.

The target user is narrow and specific. It is someone maintaining a large stylesheet who already knows CSS custom properties work fine, who does not want a Sass build step for a small project, and who is willing to invent a private vocabulary of names in exchange for shorter rules. A team that needs nesting, control flow, math functions or a module system will not find them here. The README lists the feature set and stops at values, shortcuts, snippets, mixed CSS, a browser runtime and .lcss files.

How the @lollipop block compiles into plain CSS

There is one declaration block, opened with @lollipop, and three kinds of entry inside it. A value is a bare pair, name then value, such as normalRed #FF0000. A shortcut is three tokens, name then CSS property then value, such as colorRed color normalRed, and the third token may point at a value defined earlier in the same block. A snippet is a name followed by a brace-delimited block of ordinary CSS declarations, such as normalStyle { color: #FF0000; font-size: 10px; padding-left: 10px; }.

Outside the block, a rule body may contain a shortcut name on its own line, which expands to property and value, or a snippet reference written as ...normalStyle, which splices the whole stored declaration list into that rule. Anything the parser does not recognize is passed through unchanged, which is what lets a rule mix display: grid and grid-template-columns with a textPrimary shortcut in the same body.

The README claims the parser handles nested braces, strings and comments, and that it leaves unknown CSS untouched. That matters more than it sounds: a preprocessor that rewrites unrecognized input is dangerous in a large stylesheet, and the documented behaviour here is the conservative one. The repository also has a tests/ directory with a single test entry, npm test running node tests/lollipop-css.test.js, so the parser behaviour is at least exercised by something the author wrote.

Installing LollipopCSS and writing a first .lcss file

The package is published under the name lollipop-css with main pointing at src/lollipop-css.js, and package.json declares no dependencies. The README does not give a command-line interface, so the realistic path is to pull the package and call into it from your own script, or to load the browser runtime. To get the source into a project:

npm install lollipop-css

If you would rather work from the repository, the layout is src/ for the implementation, examples/ for sample stylesheets and tests/ for the test file. The supplied example files include examples/basic.lcss, examples/style.lcss and examples/var.lcss, which is the quickest way to see the syntax in context before writing your own.

A first stylesheet follows the README's own example closely. Values come first, then shortcuts that reference them, then rules that use the shortcut names:

@lollipop {
    normalRed #FF0000
    normalSize 10px

    colorRed color normalRed
    fontSizeMd font-size normalSize
    paddingLNormal padding-left normalSize
}

.button {
    colorRed
    fontSizeMd
    paddingLNormal
}

After compilation the README shows the expected output as a normal rule with color: #FF0000, font-size: 10px and padding-left: 10px. If you see those three declarations, the block was parsed and the shortcut references resolved.

For the browser path, the README's example loads the runtime script and then links a stylesheet with a non-standard rel value, which the runtime fetches, compiles and injects:

<script src="lollipop-css.js"></script>

<link
    rel="lollipop-stylesheet"
    href="style.lcss"
>

The README also documents an inline form using a style element with type="text/lollipop", so a page can carry a small block of LollipopCSS without a separate file. Both paths assume the script is present before the stylesheet is processed.

Snippets, and the case where LollipopCSS is the wrong tool

A snippet is the closest thing here to a Sass mixin, and the README's pitch is that ...normalStyle replaces @include normalStyle. That is a real reduction in typing, and it is also the feature with the sharpest edges. A snippet is a fixed list of declarations. There is no documented way to pass an argument into it, so a snippet that needs a different colour per call site has to be duplicated or overridden afterwards by a normal declaration in the same rule. Sass mixins take parameters; this does not, as far as the README shows.

The second boundary is scope. The README documents one @lollipop block with values, shortcuts and snippets living together, and it does not describe importing one LollipopCSS file into another, namespacing definitions, or splitting definitions across files. A project with several teams editing stylesheets will end up with one shared vocabulary file and a merge conflict whenever two people add a shortcut with the same name, and the README does not say what happens when a shortcut name collides with a real CSS property name. That is the question to answer by reading src/lollipop-css.js before you put a name like padding into production.

The third boundary is tooling. There is no documented CLI, no loader for webpack, Vite or PostCSS, and no editor support. In a build pipeline that already runs PostCSS, dropping in a second preprocessor that only understands its own syntax means the two passes have to be ordered deliberately. If your project already has Sass or PostCSS with a plugin ecosystem, the typing saved here is unlikely to pay for the extra pass.

How LollipopCSS differs from Sass and from plain custom properties

The nearest alternative in spirit is Sass, and the README frames the comparison itself. Sass gives you variables, mixins with arguments, functions, loops, conditionals, partials and an import system, plus a mature toolchain and editor integration. LollipopCSS gives you values, shortcuts and snippets, and the README explicitly says it is not trying to replace CSS. The difference in approach is that Sass is a language with a compiler, while LollipopCSS is a substitution pass over a stylesheet you already wrote. That is why the README can promise that unknown CSS is left untouched: the parser has a small set of things it recognizes and no opinion about the rest.

The other alternative is doing nothing at all and using native CSS custom properties, which the README demonstrates first. Custom properties have an advantage LollipopCSS cannot match: they are resolved by the browser at runtime, so a theme switch can change --normal-red without recompiling anything. A LollipopCSS value is substituted at compile time, so a colour defined in the @lollipop block is baked into every rule that referenced it. If you need runtime theming, custom properties are the right answer and LollipopCSS is a shorter way to type them, not a replacement for them.

The honest summary is that LollipopCSS competes on ergonomics inside one author's workflow. Sass competes on capability. Custom properties compete on runtime flexibility. Pick based on which of those three you are short of.

Maintenance, licence and what the repository does not tell you

The project is MIT licensed, stated in both the README badge and the license field of package.json, with a LICENSE file at the repository root. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are kept. That is a statement about the licence text, not legal advice, and anyone embedding the runtime in a distributed product should read LICENSE themselves rather than take this summary as sufficient.

Maintenance status is easy to state and hard to predict. The last push to the default branch was on 2026-09-01, which is recent, and the repository is not archived. The README advertises version 0.2.0, package.json agrees, and no releases were retrieved, so there is no published changelog to read. A 0.x version number with no release history means the syntax could change between versions, and nothing in the repository documents a deprecation policy or a migration path for a renamed shortcut.

Upgrade cost is therefore mostly about your own stylesheets rather than the package. Because the package has no dependencies, there is no transitive tree to audit, and because the runtime is a single script under src/, updating means replacing one file. The risk sits in the @lollipop block: if a future version changes how a shortcut name is resolved, every rule that used that name changes meaning at once. Keeping the block small and the names unambiguous is the cheap insurance.

Editorial conclusion

LollipopCSS suits someone who wants to type colorRed instead of color: var(--normal-red) and does not want a Sass toolchain in the way. It is the wrong tool if you need loops, functions, imports or a mature ecosystem, because the README documents none of those. Before adopting it, read src/lollipop-css.js and run npm test, since the README does not document the error behaviour for a snippet name that collides with a CSS property.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nickhuang1121/lollipop-css on GitHub
4. README