We currently have a slightly-awkward CSS aggregation strategy. Our theme-level CSS is artificially forced to be loaded after all module-level CSS. That means we have twice as many aggregated CSS files as are necessary.
First we need to refactor all of core's CSS to be component-based. See #1921610: [Meta] Architect our CSS → Drupal core's current CSS has many issues that require our current module/theme separation.
After we refactor our module CSS to be discrete design components with low selector specificity, we can freely group module and theme CSS without worry of needing specific ordering within the aggregate file. And then we can remove CSS_AGGREGATE_THEME aggregate file and replace it with a 'weight' inside the existing CSS_AGGREGATE_DEFAULT file.
none
none
Removes the CSS_AGGREGATE_THEME constant.
Needs work
11.0 🔥
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The pre-requisite to this would be 📌 Refactor system/base library Needs work and remaining bits of #1921610: [Meta] Architect our CSS → (and any similar issues) - currently we are still loading a lot of module CSS on every page, that is only for specific core components.
Now that we can assert aggregate counts and sizes across pages in tests, it would be easy to try a patch here and see how it affects the existing (or newly added for this issue) test coverage.