Problem/Motivation
While implementing the new design system, the team raised some interest in using some of the new CSS features (mainly CSS custom properties or CSS variables). Being able to leverage these new features would lead to less overhead in the maintenance.
For example, CSS custom properties are currently supported by latest browser versions, while some older browsers are lacking support (browser support matrix). However, with the usage of CSS preprocessor, we could already reliably use CSS custom properties.
Proposed resolution
Use PostCSS to compile a version of our CSS that is supported by the browsers Drupal currently support. PostCSS is used by industry leaders including Wikipedia, Twitter, Alibaba, and JetBrains. PostCSS has over 20 000 stars in Github and is being used by almost 2 million projects according to Github.
Plugins we are currently using:
- Autoprefixer is a plugin to parse CSS and add vendor prefixes to CSS rules using values from Can I Use. It is recommended by Google and used in Twitter and Alibaba.
- PostCSS Calc reduces calc() references whenever it's possible. This can be particularly useful with the PostCSS Custom Properties plugin.
- PostCSS Custom Properties lets us use Custom Properties in CSS, following the CSS Custom Properties specification.
Dependency evaluation:
- Maintainership of the package: The library has one maintainer. He is active in the repository and PR's seem to receive his input very quickly. The library is used by 2.7 million other packages. PostCSS is also used by some large organizations including Wikipedia, Twitter, Alibaba, and JetBrains.
- Security policies of the package: Security issues can be reported privately using Tidelift. This library is only used in by core developers in development environments.
- Expected release and support cycles: Looking at the history of the library, there has been a new major release every 2 years. Only single major release is supported at the time.
- Code quality:APIs are well documented and the library has sufficient test coverage.
- Other dependencies it would add, if any:list of additional dependencies
Development workflow Q&A
How would this affect the developer workflow?
Core developers will have to run yarn run build:css while making changes to CSS. At first, this will only affect CSS in Claro but eventually, given that the tooling is there, this is something that could be expanded outside of Claro.
Would it affect only core developers, or would there be additional required steps for contrib or sites as well?
This tooling is designed to be specific to core and doesn't affect contrib in any way.
Would we handle it the way we do ES5 transpilation, with patch contributors responsible for including both the source and the compiled version, and committers' toolchains verifying it on commit?
Yes.
What's the plan for the dependency if Claro is not added to core?
This is indeed added mainly Claro in mind, but this isn't specific to Claro in any way. For example, the new frontend theme (#3064880: Create new default front-end theme) is planning to use PostCSS as well.