SugarSS and the case for indent based CSS on top of PostCSS

A syntax change, deliberately not a preprocessor

SugarSS is described as an indent-based CSS syntax for PostCSS, and the example in the readme shows the whole idea in a few lines:

a
  color: blue

.multiline,
.selector
  box-shadow: 1px 0 9px rgba(0, 0, 0, .4),
              1px 0 3px rgba(0, 0, 0, .6)

// Mobile
@media (max-width: 400px)
  .body
    padding: 0 10px

What is not in that example is the point. The readme says SugarSS is just a syntax, it changes the way you write CSS, but does not add preprocessor features built in.

That is an unusual position for something that looks like Sass. Most alternatives to CSS either are a full preprocessor with their own runtime, or are a plugin that adds one feature to PostCSS. SugarSS is the syntax layer, and the feature layer is somebody else's job, listed in the readme as separate PostCSS plugins.

The practical benefit of that arrangement is that there is no SugarSS runtime to learn and no compilation model outside the PostCSS one. Your build already runs PostCSS, so adding SugarSS means changing a parser name in a config file and renaming a few extensions.

The cost is that the feature set is a procurement decision rather than a package decision. If you want variables, you install `postcss-simple-vars`. If you want nested rules, you install `postcss-nested`. If you want `@import` handling, you install `postcss-import`. If you want `@mixin`, you install `postcss-mixins`, and with it the Sass-like `@mixin` syntax.

The project is built by Evil Martians, described as an American design and engineering consultancy for developer tools, AI and cybersecurity startups, and the author is Andrey Sitnik, who is also the author of PostCSS itself.

How indentation replaces braces and semicolons

The rules of the syntax are short and worth stating precisely, because the edge cases are where a project like this either holds up or does not.

On indentation, two spaces are recommended, but SugarSS autodetects indent and can be used with tabs or spaces. It is prohibited to mix spaces and tabs in SugarSS sources. The autodetection is a real convenience, since it means a project can adopt the syntax without first settling a formatting argument.

On multiline, there are three rules for any type of node. A new line inside brackets is ignored, a comma at the end of the line continues the node, and a backslash before a new line continues it. The readme shows all three in one block, with a media query continued by a comma and a media query continued by a backslash.

// 1. New line inside brackets will be ignored
@supports ( (display: flex) and
            (display: grid) )

// 2. Comma at the end of the line
@media (max-width: 400px),
       (max-height: 800px)

// 3. Backslash before new line
@media screen and \
       (min-width: 600px)

Within a selector you can put a new line anywhere, keeping the same indent for every line of the selector, which is how a descendant combinator spanning lines works. Within a declaration value you can put a new line anywhere too, keeping a bigger indent for the value, which is how a multi-line background or gradient is written.

The one rule that catches people out is the separator. SugarSS separates selectors and declarations by a `:` followed by whitespace, so you must write a space after the property name. `color: black` is good, `color:black` is prohibited.

Comments come in two forms, multiline and inline, and there is no silent comment. Output CSS will contain all comments from a `.sss` source. If you want Sass's silent and loud comment behaviour, the readme points at `postcss-discard-comments`.

Installing it is a parser name and a file extension

SugarSS needs a PostCSS compiler, so the setup depends on your build tool. The readme names `postcss-loader` for webpack, `gulp-postcss` for Gulp and `postcss-cli` for npm scripts, and notes that Parcel has built-in support for PostCSS.

Then you install SugarSS alongside PostCSS, with npm or Yarn. The npm form is `npm install --save-dev postcss sugarss`, and the Yarn form is `yarn add --dev postcss sugarss`.

The configuration is a `.postcssrc` file, and the only key SugarSS needs is the parser:

{
  "parser": "sugarss",
  "plugins": {
    "postcss-simple-vars": {}
  }
}

The MIME type is `text/x-sugarss` and the file extension is `.sss`.

As any PostCSS custom syntax, SugarSS has source map, stylelint and postcss-sorting support out of the box. The source map support is the practically important one, because a syntax change that loses your ability to map back to source lines will be rejected by anyone debugging their styles in the browser.

There is a second way to use SugarSS that is worth knowing about, and it is not about building. Sometimes teams use PostCSS not to build CSS but to fix source files, for example to sort properties with `postcss-sorting`. For those cases the readme says to use the `syntax` option instead of the `parser` option, so that PostCSS reads `.sss` files and writes them back out.

The repository layout shows that this is a full custom syntax implementation and not a thin wrapper. Alongside `index.js` and `index.mjs` there are `parse.js`, `parser.js`, `tokenize.js`, `stringify.js`, `preprocess.js` and `liner.js`, which is the standard set of hooks a PostCSS syntax has to provide. The package exports the syntax at the root and also exposes `./parse`, `./stringify` and `./tokenize` separately.

Mixins, functions and imports are configuration, not features

The three sections of the readme that cover mixins, functions and imports all follow the same pattern: install a plugin, add a block to `.postcssrc`, and the capability appears.

For mixins, you install `postcss-mixins` and add it with a directory:

{
  "parser": "sugarss",
  "plugins": {
+   "postcss-mixins": {
+     "mixinsDir": "./mixins"
+   },
    "postcss-simple-vars": {}
  }
}

and then define mixins in the `mixins/` directory, in a file that is itself written in SugarSS:

@define-mixin circle $size
  border-radius: 50%
  width: $size
  height: $size

For functions, you install `postcss-functions` and point it at a directory:

{
  "parser": "sugarss",
  "plugins": {
+   "postcss-functions": {
+     "glob": "./functions"
+   },
    "postcss-simple-vars": {}
  }
}

and a JavaScript file in that directory defines a CSS function, since `functions/foo.js` will define the `foo()` function in CSS:

module.exports = function (args) {
  return 'foo'
}

For imports, the readme notes that if you do not use Webpack or Parcel you need some PostCSS plugin to process `@import` directives, and `postcss-import` is the one to install. There is also `postcss-import-ext-glob`, which extends the path resolver to allow glob usage as a path, and `postcss-simple-vars` for variables and `postcss-nested` for nested rules.

The mixins example is the one that shows the design working. A mixin definition is written in the same indent-based syntax as everything else, so there is no second language to learn inside a `.sss` file.

The editor support gap is the real friction

There is a section on text editors, and reading it tells you the current state of the project rather than a polished story.

The readme lists SublimeText with syntax highlighting for `.SSS` SugarSS, Atom with `language-postcss`, `source-preview-postcss` and `build-sugarss`, Vim with `vim-sugarss`, and VSCode with `vetur` and `postcss-sugarss-language`.

Then it says they are working on syntax highlight support in text editors, and that right now you can set Sass or Stylus syntax highlight for `.sss` files. So the practical instruction today is: use your editor's Sass or Stylus mode for SugarSS files, and do not expect perfect highlighting.

That is a small thing, and it is also the kind of small thing that costs a team an afternoon of confusion on day one. A mis-highlighted file in a Sass mode will not parse the same way, since SugarSS's rules about the colon and whitespace differ from Sass's, and the highlighting will suggest structure that is not there.

The rest of the tooling story is better, because it is inherited from PostCSS. Source maps work, stylelint works, and `postcss-sorting` works. The `postcss-sorting` support is worth mentioning separately, because it is what makes the use-your-own-PostCSS-to-fix-source-files workflow practical.

The package itself is a modern one. The version is 5.0.2, the exports map has separate `require` and `import` conditions pointing at `index.js` and `index.mjs`, and there are named subpath exports for `./parse`, `./stringify` and `./tokenize` plus `./package.json`. The scripts use the Node built-in test runner with `node --test test/*.test.js`, a coverage target of 98 percent through `bnt`, `oxlint` for linting, `oxfmt` for formatting, and `postcss-parser-tests` as a shared test suite.

Where a syntax-only project is the wrong answer

There are three situations where SugarSS is the wrong choice, and the middle one is a judgement about dependency budgets rather than about CSS.

The first is a team that wants one dependency to do everything. SugarSS explicitly does not provide preprocessor features, so a project that wants variables, nesting, mixins, imports and functions is assembling four or five plugins plus a configuration file, and each one is a separate upstream project with its own release cadence and its own compatibility questions. If the appeal of a preprocessor was that it was one thing, this is not that.

The second is a codebase with a large existing stylesheet. The migration is a rewrite of every rule in the file, not a search and replace, and there is no automated path described for it. The syntax change also alters the shape of the source in ways a reviewer has to read differently, so a conversion of a few thousand lines is a project in itself.

The third is anything that needs a language feature CSS itself does not have and that the ecosystem has not standardised on. SugarSS changes how you write CSS, not what CSS can express. Custom properties, container queries, cascade layers and the rest of the modern CSS platform are available in the output regardless of which syntax you wrote it in, and SugarSS adds nothing to that list.

There is also a quiet maintenance point in the release history. The three most recent releases are 5.0.0 on 2024-11-20, 5.0.1 on 2025-07-30 and 5.0.2 on 2026-10-07, with the last push on 2026-10-07. The project is not archived, and the two year gap between 5.0.0 and 5.0.1 followed by a quiet fourteen months before 5.0.2 suggests a project that is maintained rather than busy. For a syntax layer that is a reasonable trade, since the language it targets changes slowly, but it does mean you should expect to run an older version of the surrounding PostCSS plugin ecosystem than you would with a busier project.

Editorial conclusion

SugarSS fits a team that likes Sass's readability but does not want a separate compiler and a preprocessor with its own semantics, and that is happy to assemble variables, nesting, mixins and imports from individual PostCSS plugins. It is the wrong tool if you want one dependency that does everything, because the feature set is deliberately spread across plugins you install and configure yourself. Before adopting, verify two things: that the plugins you would need exist and are maintained, since SugarSS itself adds none of them, and that your editor highlights `.sss` files correctly, because the documentation says you can currently set Sass or Stylus highlighting for those files. The code is MIT licensed, the current release is 5.0.2 from 2026-10-07, and the last push was on the same day.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. postcss/sugarss on GitHub
4. README
5. Releases