Research Emotion as a CSS solution

[thrbnhrtmnn]

Description / User story

We want to invest some more time too investigate if Emotion 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

Acceptance Criteria

• Emotion 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

Emotion seems promising on first glance as it is largely API compatible to lit's css tag function and supports dynamic template expressions all the way through. I took the library for a first spin to see if it would work with lit and shadow dom and so far it works although we'd have to implement some glue code and shared mechanisms at the element base level to comfortably make use of the library inside lit. Dealbreakers like SSR support and performance have to be investigated still.

Pros

No additional build tooling required.
Completely dynamic creation of css possible.
Offers stable dev tooling for css editor highlighting, auto completion and linting.
postcss-styled-syntax for linting with stylelint
vscode-styled-components for css syntax highlighting and autocompletion
Style rules are automatically vendor prefixed.
Support for nested css.
Further CSS output customisation possible via stylis plugins.
Supports both - tagged template style syntax and object style syntax.
Supports custom class names as well as auto generated ones so it can be adopted incrementally. The best way to implement this still has to be figured out though.
Familiar to developers that used styled-components in the past.
Seems well maintained.
Well documented.
Cons

We might have to write some amount of glue code to make it work comfortably with Lit.
Might impact performance negatively due to the completely dynamic nature. Emotion inserts <style> nodes into other DOM nodes during runtime. These style nodes need to either be shared across component instances by using the ShadowRoot.adoptedStyleSheets property or have them duplicated and re-evaluated per instance. We have to find a clever way to minimize style evaluation across instances.
SSR feasibility should be thoroughly investigated before deciding in favour of emotion.
Comes with a runtime dependency. Impacts bundle sizes by about +15 kB.

Code of Conduct

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

[thrbnhrtmnn]

After #1096 this might not be the best solution anymore, as we see a risk that emotion would not work with our ssr solution