Support for nested `modeSelectors` in CSS Plugin

[michaelurban]

Being able to nest selectors would be useful. For example nesting an @support at-rule inside of an @media at-rule by allowing arrays of selectors.

Desired Config:

export default defineConfig({
  ...
  plugins: [
    css({
      modeSelectors: [
        {
          mode: "media-supports",
          selectors: [
            "@media (prefers-color-scheme: light)",
            [ <-!!! Multiple selectors, nested in array order.
              "@media (prefers-color-scheme: dark)", 
              "@supports(<supports condition>)"
            ]
          ],
        }
      ]
  })
});

Desired Output:

@media (prefers-color-scheme: dark) {
  @supports (<supports condition>) {
    ...
  }
}

@media (prefers-color-scheme: light) {
  ...
}

[drwpow]

Thanks for the suggestion! Just so I’m understanding, is there any advantage to doing this over say @media (prefers-color-scheme: dark) and @supports (<supports condition>)? With the modes declared wouldn’t the specificity be the same?

[michaelurban]

is there any advantage to doing this over say @media (prefers-color-scheme: dark) and @supports (<supports condition>)?

I think putting it all into one string would be awkward for a few reasons:

0. Chaining at-rules isn't valid CSS, so users are going to have to think in and write invalid CSS.
1. The strings can get long if you have multiple selectors.
2. You're going to have to parse "@media(<xyz>) and @supports(<condition>)" and turn it into ["@media(<xyz>)", @supports(<condition>)] before emitting the rules anyway.

With the selectors in a list you it's easy to group and nest rules. Example:

export default defineConfig({
  ...
  plugins: [
    css({
      modeSelectors: [
        {
          mode: "dark-media-supports-0",
          selectors: [
            [
              "@media (prefers-color-scheme: dark)", 
              "@supports(<supports-condition-0>)"
            ],
          ],
        },
        {
          mode: "dark-media-supports-1",
          selectors: [
            [
              "@media (prefers-color-scheme: dark)", 
              "@supports(<supports-condition-1>)"
            ],
          ],
        }
      ]
  })
});

Can emit the following without parsing:

@media (prefers-color-scheme: dark) {
  @supports (supports-condition-0) {...}
  @supports (supports-condition-1) {...}
}

---

Going a Step Further:

I'd actually go further and say that modeSelectors should be nestable:

(just a sketch off the top of my head)

{
  ...
  "modeSelectors": [
    {
      "mode": "dark",
      "selectors": [
        "@media (prefers-color-scheme: dark)",
        "[data-mode=\"dark\"]"
      ],
      "children": [
        {
          "mode": "dark-supports-condition0",
          "selectors": "@supports (condition0)"
        },
        {
          "mode": "dark-supports-condition1",
          "selectors": "@supports (condition1)"
        }
      ]
    }
  ]
}

Which would emit:

@media (prefers-color-scheme: dark) {
  @supports (condition0){...}
  @supports (condition1){...}
}

[data-mode="dark"] {
  @supports (condition0){...}
  @supports (condition1){...}
}

[drwpow]

Oh! Thank you. I was getting my wires crossed. You can use and with the same at-query, but not join 2 different at-queries you’re right.

I’m on board to the idea! I’d just like to bikeshed alternate syntaxes to this. I actually like the 2nd proposal of nesting modeSelectors better. One thing I think is important to communicate to folks is “we are going to redeclare all your tokens for every modeSelector and there is no way around this.” Some folks think some clever optimization is happening here, but we’re really just dumping all matching tokens over and over again for every array item. Because that’s how CSS needs to work (I just realized I need to add a few sections to the CSS docs outlining some of the finer points about this). And perhaps allowing an array of selectors was a design mistake because it’s often not clear how that generates CSS.

Anyway, having a clearer 1:1 relationship between 1 modeSelector == 1 token dump like your 2nd proposal is good. I would like to bikeshed a bit and explore alternate syntaxes though! Because I wonder if there is an even simpler way to express this, that folks would find themselves writing without even having to read the docs

[michaelurban]

@drwpow

Cool.

The particular config syntax is less interesting to me than the functionality.

Personally, I like the way Django uses unlabeled nested tuples/lists for model choices. But I wouldn't recommend feeding your users to that.

Let me know if there's anything that I can do to help.