Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support composes at-rule #351

Open
jonathantneal opened this issue Jul 10, 2020 · 3 comments · May be fixed by #352
Open

Support composes at-rule #351

jonathantneal opened this issue Jul 10, 2020 · 3 comments · May be fixed by #352

Comments

@jonathantneal
Copy link

jonathantneal commented Jul 10, 2020

Problem: Composition and the Cascade

CSS Modules lets us extend classes using the composes declaration. When extending multiple classes, CSS Modules requires multiple composes declarations. Here is an example of what that CSS looks like:

.some-call-to-action {
  composes: link from 'link-styles.module.css';
  composes: button from 'button-styles.module.css';
}

The issue is that this practice of writing multiple composes declarations defies CSS Cascade (the "C" in "CSS"). Therefore, using multiple composes declarations becomes a non-preferable practice.

Only CSS declarations, that is property/value pairs, participate in the cascade.
https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade

In CSS, properties overwrite each other, and they do not combine with each other. Here is an example of the cascade:

/* global.css (earlier in order) */

li {
  margin-left: 10px;
}
/* project.css (later in order) */

li {
  margin-left: 0; /* This is a reset of `margin-left` */
}

Note: That example is used in MDN’s introduction to the CSS Cascade.

Authors may also rely on this cascade to manage browser fallbacks (e.g. .layout { display: block; display: grid }).

Even the singular example from this project’s documentation of composition relies on this expectation.

Solution: Composition At-Rule

Please consider supporting a @composes at-rule, which would be functionally identical to the current composes declaration. This would allow authors to utilize composition while still respecting the expectations inherit to CSS.

Here is an example of what that CSS would looks like, mirroring the opening example:

.some-call-to-action {
  @composes link from 'link-styles.module.css';
  @composes button from 'button-styles.module.css';
}

Additional unintentional benefits include:

@alexander-akait
Copy link
Member

alexander-akait commented Jul 10, 2020

Sounds good, but it will be breaking change, but we can keep both syntaxes for compatibility

@jonathantneal jonathantneal linked a pull request Jul 10, 2020 that will close this issue
@jonathantneal
Copy link
Author

jonathantneal commented Jul 10, 2020

Thank you so much for considering this, @evilebottnawi. I am also fully in favor of keeping both syntaxes for compatibility.

What could I do to help facilitate this change, from a position of code contributions? I’ve created #352 as a work-in-progress proposal of documentation changes. I would be happy to commit code changes in PRs to the appropriate plugins as well.

@alexander-akait
Copy link
Member

We need to send a PR for this to https://github.com/css-modules/postcss-modules-scope/blob/master/src/index.js and https://github.com/css-modules/postcss-modules-extract-imports, I think we can implement this, sounds good

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants