Baseline set of tools for CSS

[romainmenke]

Assumptions

Authors use CSS in very different ways and I think that everyone should be free to do as they want.
However I think it is important to narrow the scope to make things feasible and to help the most people.

I also think that really really good CSS support has been hampered by trying to support too many non-standard approaches. (e.g. loading symbols from other files becomes trivial once we agree how stylesheet combine)

The base assumptions always are:

• no custom syntaxes
• CSS is written in a .css file (not that the extensions itself matters)
• no CSS modules (the pre-processor thing)
• CSS is served to the client as CSS
• importing and applying stylesheets follows CSS rules

Constraints

• tools must be written in JavaScript¹
• tools must be extensible (but only within the language²)
• contributing to tools must be easy and safe
• performance of tools is not a goal in and of itself

Tools

Tokenizers / Parsers

Existing tools:

• https://github.com/csstree/csstree
• https://github.com/postcss/postcss
• https://github.com/csstools/postcss-plugins/tree/main/packages/css-tokenizer
• https://github.com/keithamus/csslex
• ...

I think this area is well covered.

TODO:

• support existing projects

Language Server

A single shared language server can be shared by all editors.

The current situation in VSCode illustrates the need for a good language server that is owned by the community and not by a single editor.

I tried looking for one that isn't the current VSCode language server but every result I found was an archived repo...

TODO:

• investigate if any existing tool could be used
• alternatively gather funds and start a new project

Package manager support

Surprisingly it isn't standardized how stylesheets can be distributed through package managers.

This causes everyone to do their own thing:

• vendor lock-in
• author confusion
• lack of docs and editor support

I don't think there is a need to create a new package manager, existing solutions work just fine.

Two things should be standardized:

• how do you reference a package (e.g. @import ("node_modules:foo/bar.css"))
• how do you describe that a package contains stylesheets (e.g. { "style": "foo/bar.css" }) (see: doc: add style/sass/less export conditions nodejs/node#46994)

Standardizing these aspects will drive interop between tools.

TODO:

• standardization effort

Tests

end to end tests

Tests can provide safeguards when making changes and give insights into large codebases.

A lot of non-standard efforts in CSS essentially boil down to:

• having absolute control and tied coupling
• being able to write any styles without needing to coordinate with other team members

But the root of both is that any change to stylesheets might have some unexpected result somewhere else.

Tests I would find interesting:

• dead code analysis
• overriding existing named things
• multiple imports of the same stylesheet
• invalid styles (not by syntax, but in context)
• unexpected overflows

For JavaScript it has become accepted that writing tests require starting up a headless browser, running some steps and making assertions.

For CSS we already have a ton of information available in things like Chrome dev tools and yet we don't have any way to test these automatically.

Better integrations with browser dev tools and dedicated test helpers for CSS would be awesome.

unit tests / fuzz tests

More and more powerful and dynamic features are being added to CSS:

• mixins
• custom functions
• custom units
• relative colors
• math functions like clamp

A common question I have in all these often is: "can the outcome ever be unexpected"

conclusion

Writing tests for CSS is almost never done.
And yet we see the rise of things like TailwindCSS, CSS modules, CSS-in-JS, ...
These non-standard solutions offer support and guardrails that lack in native CSS.

Investigating what can be done for CSS authors seems important to me.
I don't want CSS to become a compile target purely because people don't feel comfortable and safe when writing styles.

This is a moonshot, but something we should try again and again 😛

TODO:

• investigate what is possible

Build/Bundle

Because of the horror that is the speed of light it will always be worse to have a waterfall pattern when loading resources and bundling will remain a good pattern.

Tools must agree on how bundling works:

• to avoid vendor lock-in
• to be able to distribute unbundled CSS packages
• to avoid author surprise

This is one area I have already been working on:

• a test suite: https://github.com/romainmenke/css-import-tests
• a reference implementation: https://github.com/csstools/postcss-plugins/tree/main/plugin-packs/postcss-bundler

Any tool should be free to optimize, but ideally bundling with any tool results in the same effect on a page.

TODO:

• support existing projects
• promote interop between tools

Formatter

Existing tools:

• https://prettier.io
• https://github.com/stylelint-stylistic/stylelint-stylistic

Something that surprises me a bit about these tools is that CSS describes how to serialize and normalize CSS and that these tools do that work all over again.

Do authors disagree so strongly with the CSS serialization rules or is this just because tool creators weren't aware?

I think this area is well covered.

TODO:

• support existing projects

Static Analysis / Linter

Existing tools:

• https://stylelint.io

I think this area is well covered.

TODO:

• support existing projects

Unified toolchain?

A single CLI might be a nice additions.

css fmt
css build
css watch
css ...

This could be a thin wrapper around existing tools with good defaults.
Then authors can simply do npm install css and immediately have a full and rich setup.

Not that css is available as a package name, but would have been so neat...

Documentation about tools

Anyone new to CSS should be able to visit a single site and learn all about the baseline set of tools for writing CSS.

This site should not claim that no other tools exist and should actively link to alternatives or more advanced approaches.

Footnotes

1. JavaScript is the language that is most accessible for most CSS authors. Being able to hack and improve the tools that you use is really important and in the spirit of the open web. ↩

2. CSS has a long standing convention that any named thing that starts with double dash is user defined. So any of those are fair game for extensions. (e.g. @--csstools-custom-thingy foo;) This isn't pretty but it isn't supposed to be. It is supposed to be conflict free. ↩