[selectors-5] “initial state” selector

[bramus]

I recently had a chat with @jantimon about not being able to set the background-color of a button but only if that button is in initial state.

Effectively, the code they have is this:

@layer base-ui {
  button {
    background: red;
    &:disabled {
      background: purple;
    }
  }
}

@layer shop {
  .primary {
    background: orange;
  }
}

The problem for them is that the background-color of the .primary:disabled also becomes orange, due to the declaration in the shop layer. Ideally, they want to overwrite the background-color only for the .primary in its initial state (no :hover, no :active, no …).

---

As for some workarounds I suggested them to either:

1. Use Custom Properties:

   @layer base-ui {
     button {
       background: var(--bg, red);
       &:disabled {
         background: purple;
       }
     }
   }
   
   @layer shop {
     .primary {
       --bg: orange;
     }
   }

2. Target all non-states

   .primary:where(:not(:disabled, :hover, :active, :focus, :focus-visible)) {
     background: orange;
   }

   You can see this one in action at https://codepen.io/editor/bramus/pen/019fb84d-6030-7a93-85c5-41231540f5b8/1b5c8b2345114c13a70d48674240c349

3. Carefully curate the layers

While these workarounds do work, each one has issues or complexity involved:

1. Not everyone can just rewrite their code to use custom props
2. The non-state selector would require you to list all states … and then also update that selector should more states become available over time.
3. Carefully curating the layers seems tedious, especially in larger codebases. As Jan told me: “we have a medium sized app with 8.000+ files - we can't sort all of these into layers and keep track which wins or loses in which scenario”

---

Maybe we could offer authors a “initial state” type of selector, so that they can target an element in its initial state?

Something like this:

@layer shop {
  .primary:initial-state {
    background: orange;
  }
}

[keithamus]

Presumably custom states also apply here? So e.g. :state(foo):initial-state could never match.

What about pseudos where the element is always in one-state :dir(), :heading?

Perhaps we should avoid the word initial given that an element can return to this state after losing focus/hover/active/etc. Perhaps :no-state.

[bramus]

Presumably custom states also apply here? So e.g. :state(foo):initial-state could never match.

:state(none) as a selector then, perhaps? That way it’d be clear that they can’t combine. Or is :state() reserved for only custom states?

What about pseudos where the element is always in one-state :dir(), :heading?

Is :heading a state?

Perhaps we should avoid the word initial given that an element can return to this state after losing focus/hover/active/etc. Perhaps :no-state.

Yeah, also works.

[romainmenke]

Carefully curating the layers seems tedious, especially in larger codebases. As Jan told me: “we have a medium sized app with 8.000+ files - we can't sort all of these into layers and keep track which wins or loses in which scenario”

I think that is an issue with how cascade layers are now popularly used.
Authors really like using them to organise bits of code into labelled buckets.

We tried this for one project and immediately stopped doing this.
Not being able to use specificity to carefully override specific bits of CSS was too much of a drawback. Being able to interleave an override is a crucial tool and cascade layers make that impossible.

I am still really hoping that this anti-pattern goes away again and that people use more appropriate tools like @scope to avoid conflicts in such large codebases.

---

In the future mixins could also be an interesting tool.
You could add extension points all over your code base:

@layer base-ui {
  button {
    background: red;

    @apply --base-ui-button();

    &:disabled {
      background: purple;

      @apply --base-ui-button--disabled();
    }
  }
}

mixins are globally defined, so for element specific overrides custom props remain the best option I think.

---

I am not opposed to something like :no-state but I also don't think this solves the underlying problem. It only covers one very specific case.

&:disabled could also be &[data-bar] in some other case and that won't be solved by :no-state.

If there are plenty of other use cases for :no-state then it might still be a good addition :)

[bramus]

I am not opposed to something like :no-state but I also don't think this solves the underlying problem. It only covers one very specific case.

Yes, in his post on Bsky, Jan detailed some other examples that are related to this underlying problem.