Support for manually ordering rules in the rare case it's needed

[DanielHeath]

I have run into a slightly obscure case while overriding the rendering of an inline SVG by using !important to override its attribute styles.

I'm using this to change the fill color on hover.

  svg {
    fill: var(--svg-highlight-color) !important;
    &:hover {
      // touch browsers treat tapping on an SVG element as a hover
      // that lasts until you touch elsewhere, which breaks our
      // color toggling, so only implement hover if available.
      @media (hover)  {
        --svg-highlight-color: var(--icon-hover-state);
      }
    }
  }
  // When the button is disabled, we want no hover behavior
  // Must be last to override everything else
  [disabled] svg, [disabled] .FontAwesomeIcon_composed {
    --svg-highlight-color: var(--icon-disabled-state);
  }

Any idea how to adapt this to vanilla-extract? It (eg) moves media queries to the end, which breaks this pattern.

[DanielHeath]

Related:

#141

#734 (similar topic, but this is a specific use-case rather than "I want X")

[michaeltaranto]

Hey Daniel, it'd be great if you could share a basic example of the end result in a codepen (or similar). Demonstrating the desired static HTML and CSS you are after.

Once we have a working example, should be able to recommend the right approach using VE.

[DanielHeath]

Sure.

https://codepen.io/0xb4d1dea/pen/MWGjvMX is a basic example of how moving the media query after the [disabled] style causes a regression.

[DanielHeath]

Looks like I can duplicate the [disabled] style into the media query, which fixes it at the cost of a few wasted bytes for the duplication.

[michaeltaranto]

Ok i have a few options:

Option 1. Ensure the svg is not within a disabled container as part of the selector:

svg path {
  fill: var(--icon-color, blue);
}
[disabled] {
  --icon-color: grey;
}
@media (hover) {
  div:not([disabled]) svg:hover {
    --icon-color: red;
  }
}

This requires consistent HTML, e.g. wrapping elements (ideally a button?) regardless of disabled state.

Option 2. Disable pointer events on disabled containers

svg path {
  fill: var(--icon-color, blue);
}
[disabled] {
  --icon-color: grey;
  pointer-events: none;
}
@media (hover) {
  svg:hover path {
    --icon-color: red;
  }
}

The VE code for the latter option would look something like this:

import { createVar, fallbackVar, globalStyle } from '@vanilla-extract/css';

const iconColor = createVar();

globalStyle('svg path', {
  fill: fallbackVar(iconColor, 'blue')
});

globalStyle('[disabled]', {
  vars: {
    [iconColor]: 'grey'
  },
  pointerEvents: 'none'
});

globalStyle('svg:hover path', {
  '@media': {
    '(hover)': {
      vars: {
        [iconColor]: 'red'
      },
    }
  }
})

I would personally be leaning into scoped rules rather than using global selectors, but that is for you to asses based on your requirements.

Hope that helps.

[DanielHeath]

Thanks for that!

For evaluation purposes, I was porting existing components, keeping their markup as-is. It looks like some of the patterns we use are awkward in VE (for good reasons!).

Overall my impression is that the DX is extremely good; I'm definitely noticing the lack of debug identifiers (with esbuild) but otherwise everything is very, very nice. Fantastic work by the team!

[michaeltaranto]

Glad the examples help.

Hard to talk to how awkward or not the patterns would be in VE given the abstract examples we are talking to, but hopefully seeing some of the before and afters above help to work through your migration options.

[DanielHeath]

For components which don't accept child arguments (no concern of clobbering unrelated components), I'll often use ugly shortcuts like .foo ul instead of applying a class to the ul because it's a few seconds faster to write.

Using VE will push me to use classes instead, since it'll be as easy to add the class as it is to add a globalStyle section.

[mattcompiles]

I'm definitely noticing the lack of debug identifiers (with esbuild)

@DanielHeath We'll be shipping automatic debug Ids in esbuild very soon. PR is open now #827.