Research SASS as a CSS solution

[thrbnhrtmnn]

Description / User story

We want to invest some more time too investigate if SASS is a potential CSS library to use, as recommended by #1081 .

The following key factors need to be considered:

• Supports Server Side Rendering (SSR)
• Supports code driven transformation of CSS (either at build-time or runtime)
• Provides a satisfying developer experience which includes:
• Syntax highlighting
• Context aware editor auto-completion, code navigation and refactoring
• CLI validation tools
• Extensive documentation
• Allow for targeted style overrides from outside the component
• Allow for targeted style re-use from outside the component

Requirements / Prerequisites

• Research CSS Improvements #1081
• Evaluate Server Side Rendering (SSR) capabilities of lit with example applicaiton #1096
• Research Emotion as a CSS solution #1097
• Research Vanilla-Extract as a CSS solution #1098

Acceptance Criteria

• SASS has been evaluated by the key factors we defined for a CSS solution
• The outcome has been documented
• We are able to decide on the CSS approach after further research of Vanilla Extract and SASS has been finished

Additional information

Current findings as researched via #1081

While css-in-js is a powerful tool it can come with a host of issues such as:

Unfamiliarity for people who are used to writing more traditional CSS
Bad tooling integration
Configuration overhead
Complexity
While the most popular libraries out there try to tackle these issues head on by sticking close to standard css syntax and by providing extra tooling - those tools are often plenty, might not play well with other tools or might be maintained by different people featuring various levels of quality.

So to minimise the amount of dependencies and tooling needed we could opt for a more traditional and proven css approach like using SASS in conjunction with build-time plugins like postcss-scss, babel-plugin-transform-postcss, webpack postcss-loader or webpack css-loader to inject those styles into our javascript.

This approach should theoretically be compatible with our current Lit style declaration but has a few potential shortcomings that we need to look at in more detail. Namely:

css-modules aren't natively supported in typescript. This means that we have to take extra care not to end up with unmanaged, loosely-coupled class name references. Our build script should ideally throw an error when we try to reference non-existing css class names.
typescript-plugin-vscoce for editor support
SASS might not be a powerful enough language to support our TokenIterator concept.
We have to implement a SASS output target for our figma-design-tokens package.
Overall i think that this approach is worthy of further investigation as it could lead to a much better dev experience.

Code of Conduct

• I agree to follow this project's Code of Conduct

[thrbnhrtmnn]

Improving our current CSS approach with #922 and #1021 (and follow up tasks for all other components to remove class maps) seems to be the more safe next steps than to invest time in this task.