RFC: @inherits for easier composition of multiple styles

[tivac]

Feature Use Case

modular-css already supports wildcard values like @value * from "./file.css"; that basically sucks in all values from the specified file and makes them available in the local scope.

Something like that for classes/IDs would be pretty convenient as well.

Feature Proposal

@inherits: "./file-to-inherit-from.css";

/* file-to-inherit-from.css */
.rulea {
    color: red;
}

.ruleb {
    color: blue;
}

/* inheritor.css */
@inherits: "./file-to-inherit-from.css";

.rulec {
    /* no file specifier needed, because of @inherits above .rulea is considered local */
    composes: rulea;
    
    background-color: red;
}

would export

const css = require("./inheritor.css");

// css is
/*
{
    rulea : "abcd123_rulea",
    ruleb : "abcd123_ruleb",
    rulec : "abcd123_rulea dcba_321_rulec"
}
*/

[stffrd]

Is this really any different than:

/* file-to-inherit-from.css */
.rulea {
    color: red;
}

.ruleb {
    color: blue;
}

/* inheritor.css */
.rulec {
    composes: rulea from "./file-to-inherit-from.css";
    
    background-color: red;
}

I guess I'm more curious as to what problem this is trying to solve?

Is it having too many @value statements?
There's a level of explicitness that I really like about mcss, especially knowing if I see a composes key in the wild I can reasonably know almost immediately where it's coming from because it's either composes: thing from "./file.css" or composes: thing from base where base is an @value.

[tivac]

@stffrd in your example this is the output from the CSS file.

const css = require("./inheritor.css");

//css is
/*
{
    rulec : "abcd123_rulea dcba_321_rulec"
}
*/

if you wanted to also get .rulea and .ruleb in there you would need to do this.

/* inheritor.css */
@value parent: "./file-to-inherit-from.css";

.rulea {
    composes: rulea from parent;
}

.ruleb {
    composes: ruleb from parent;
}

.rulec {
    composes: rulea from parent;
    
    background-color: red;
}

which is already annoying me with 3 rules, and if I imagine 10+ it seems nightmarish.

[stffrd]

Oh I see. Yeah I can see this being different enough that it'd be useful!

[tivac]

Feedback from a chat:

not sure about the naming "@inherits". Can you only have a single @inherits? chain inheriting allowed? i feel like you may have some tricky edge cases in implementing this ><

can a parent compose from child file?

I think renaming this is probably a good plan, maybe instead of @inherits it could be @composes. I was originally worried about overloading "composes" but the difference between a property in a rule and a top-level at-rule is probably enough? It does a better job of getting at what this does than @inherits at the very least I think.

Other thoughts based on this feedback:

• You can only have one @composes per file
• Each @composes can only reference a single other file
• Circular dependencies are still not allowed, so you can't do something like have the parent also use composes against a rule in the child. I'm not sure what world that would make much sense in, but the obvious solution to my mind is to move the shared rule out into a separate file that both parent & child can use composes against.

[kevinkace]

Not having to do

.rulea {
    composes: rulea from parent;
}

or

import css from "./index.css";
import css2 from "../../someOtherCss.css";

sounds rad!

[tivac]

Released in v24.2.0 as @composes, see https://m-css.com/guide#composing-files