How to use composition in elements without className?

[hnqso]

@geelen I'm following your suggestion and creating a healthy issue to discuss this.

What do you recommend for the follow scenario:

.docs h3 { 
  composes: color;
}

.page h3 { 
  composes: color;
}

I'm re-writing the page/docs for Minigrid and I'm using markdown-loader for generate content for both. I can use my own markdownLoader to parse the text, add the classNames and give it back to the webpack. For this simple case it works fine, however my concern is when the project grows this could become problematic. I'd like to be able to achieve this without have to overwrite the loader and parse the content.

Thoughts?

Thanks 🍺

[hnqso]

Btw, I forgot to mention that @nkbt suggested before the use the :global which I already added and works fine if I'm dealing with only one context e.g. the docs page.

[nkbt]

I believe that styling html tags is unsafe and goes against css-modules core concept. Since if you have nested components (which you always have), you get into old good "inheritance" and specificity issues. Maybe this could be also automated somehow, but not sure, since we cannot manipulate rendered html.

[hnqso]

@nkbt I hear you and as I told you before I don't mind at all 😊 after start using React I drop the html tags styling.

It's just because I use markdown a lot and I can see other cases where I'd use a loader e.g. YAML which will return a "pure" HTML and I'd have again to overwrite the loader and parse it. Just wondering if we could achieve or even hack something around only for this cases.

[nkbt]

By the way that sounds like a good idea to PR yaml-loader to add classes to each element ;)

<h1 class="h1">

[hnqso]

@nkbt yup! Nice one!

[nkbt]

oh sorry that would not work for obvious reasons.. disregard previous comment.

[hnqso]

@nkbt 👍 going to wait for Glen to see if he has any suggestions if not I'm happy to close this issue.

[geelen]

Ok, so. Yes. This is a problem. Let me give you some background (maybe you're already across this but for other readers of this issue):

composes works by exporting multiple classnames from the CSS. So, when you have

.foo {
  color: red;
}
.bar {
  composes: foo;
  background-color: blue;
}

import styles from "./foo.css";

return "<p class='${styles.bar}'>Content</p>"

You get the following ICSS:

:export {
  foo: foo_98812cadf;
  bar: foo_98812cadf bar_312cbca63;
}
.foo_98812cadf {
  color: red;
}
.bar_312cbca63 {
  background-color: blue;
}

So, your HTML renders out as <p class='foo_98812cadf bar_312cbca63'>Content</p> and you get all of .foo and .bar styles. But the only way that works is through classes. Think of composes as an instruction to JavaScript to include this extra class whenever you reference this one. It relies on dynamic markup to work.

So if you don't have control over the markup being injected then composition doesn't work.
.foo :global(p) will still give you localisation, of course, but if you're building your whole site using composition that's not ideal.

I actually faced this exact problem and wrote a monstrous JSPM loader for it. It parses the markdown as YAML (for frontmatter), then markdown then JSX, then returns an ES6 function that accepts a styles object. I think. I can never remember, I wanted to tidy it up and release it but it breaks if I touch it...

It gets used here and lets me do cool stuff with inline JSX in markdown:

But I digress, back to the issue at hand.

---

Theoretically, you could write a runtime JS component that gave you this more advanced behaviour, where it watches the live DOM and attaches classes based on these more advanced rules. That could be kind of neat, but at this stage it's not something I'm going to work on. For one, I am trying to avoid using descendent selectors & bare tags as much as possible, except for contextual overrides that don't care about the nature of the things they're overriding. E.g:

.MyComponent {
  > * {
    margin-top: 1rem;
  }
  > :first-child {
    margin-top: 0;
  }
}

Secondly, if you add a runtime dependency you need to be damn careful not to break server-side rendering. Because all the React SSR stuff already evaluates the render tree, injecting classnames there works really nicely. And since we're using plain-old-CSS, we get pseudo-selectors like :hover for free (Radium has problems with that). I think we can do it, but I'm not sure if it's worth it. And if we want to support traditional stuff like Rails (which we should!)

---

Probably should also point out that the following usages of composes don't work for the same reasons:

.foo .bar {
  composes: different-when-nested;
}

@media (max-width: 599px) {
  .bar {
    composes: something-on-small-breakpoint;
  }
}

The media query one, at least, has a decent fallback:

/* A class can use media queries then get composed */
.headline {
  font-size: 4rem;
}

@media (max-width: 599px) {
  .headline {
    font-size: 3rem;
  }
}

/* You can use suffixes like Tachyons/Basscss */
.foo {
  color: red;
}

@media (max-width: 599px) {
  .foo--small {
    color: red;
  }
}

.bar {
  composes: headline foo--small;
}

The thing I like about this is that we're building our own abstractions on top of the basic CSS mechanisms. I see composes as constrained, yes, but it feels like it's worth embracing this constraint for the time being to see where it leads us :)

[NekR]

@geelen composes is really good idea and having classes for everything is mostly fine. But, some times it's enough. For example I may want to style html/body with default brand styles, but this won't work since :global does not support composing as far as I understand. Of course, everything can be done and detected in JS, but there is a good reason why people prefer writing basic things in CSS--they are basic, easier and probably faster when are written in CSS.

Adding dynamic classes to default elements such as html/body can really be a pain. It means that main html file for SPA should go through the save manager as JS/CSS (let's say webpack) and it's not easy now-days. You probably should have merges/extends/copies/whatever which only works for tag selectors (although one may want to apply them to IDs).

[hnqso]

Thanks @geelen for the background, for spending time writing this.

So if you don't have control over the markup being injected then composition doesn't work.
.foo :global(p) will still give you localisation, of course, but if you're building your whole site using composition that's not ideal.

I think this is one of the problems I face right now building a site, not an app or component.

For one, I am trying to avoid using descendent selectors & bare tags as much as possible, except for contextual overrides that don't care about the nature of the things they're overriding

Couldn't agree more. CSS modules is all about simplicity.

I actually faced this exact problem and wrote a monstrous JSPM loader for it. It parses the markdown as YAML (for frontmatter), then markdown then JSX, then returns an ES6 function that accepts a styles object.

Ok that's interesting thanks for sharing. I think a variation of your markdown.js could be used as markdownLoader on webback if you're using CSS modules.

I can never remember, I wanted to tidy it up and release it but it breaks if I touch it...

😂😂😂

The thing I like about this is that we're building our own abstractions on top of the basic CSS mechanisms. I see composes as constrained, yes, but it feels like it's worth embracing this constraint for the time being to see where it leads us :)

I agree! I think is worth to apply this in real projects. Right now I have the feeling that CSS modules is perfect for components and self-contained apps, but for page layout/design I think we are still missing some pieces. I know @markdalgleish made react-themeable to address some of the limitations but this isn't an issue with theming. Maybe we need something else in between 😊.

I'm happy with the answer, please feel free to close this issue.

Cheers 🍺

[geelen]

@NekR I'm afraid it's simply not possible to use composes with tag selectors. What you want is the @extend CSS spec proposed by Tab Atkins.

But, while I'm finding plenty of uses for composes, by no means is it the only way to use CSS Modules. Not all styles have to be written the same way, not all duplication needs refactoring. One of the benefits of CSS Modules is that it's still just CSS, you can use a few tag selectors if you need to (using :global) and use composes for the rest.

Oh, that and it's all just PostCSS transforms so if you want to go crazy and write a stage that detects if composes is used inside a tag selector and goes and copies the referenced rules (just like a Sass mixin) you could totally do that! ;)

[nkbt]

By the way we never used `composes` and used only simple 1 level deep classes in our css. Composition was done with react components itself. If something looks same - it is a component that can be reused in many situations. You can even go more crazy doing simple component-wrapper, the only thing that it would do - make text color `red` on passed child (via classname), for example. This kind of comletely eliminates the need in css-modules `composes` I am keen to see how it will go on a scale though.

[NekR]

@NekR I'm afraid it's simply not possible to use composes with tag selectors. What you want is the @extend CSS spec proposed by Tab Atkins.

I do not propose to use compose with tag selectors or even compose action behind the scene. For other selectors than classes we need this:

:global(body) {
  margin: 0;
  / * ... */

  add/merge/whatever: text-color from './colors.css';
}

which would produce:

body {
  margin: 0;
  / * ... */

 color: #333;
}

but not any magic from compose. This probably should be allowed only when selector is marked as :global().

Oh, that and it's all just PostCSS transforms so if you want to go crazy and write a stage that detects if composes is used inside a tag selector and goes and copies the referenced rules (just like a Sass mixin) you could totally do that! ;)

I did not say that it should be still called composes for such case. I understand that it's PostCSS and could be done. I could understand the case when you ask people to contribute to the project, this is fine. But why you are so defensive about adding new features? It would be a bit unfortunate to adding one more PostCSS transformer to load modules, define variables, define all in vars, then in css-module to be able to compose them, etc. merge rule really can help here.