Props discovered, that contain adaptive props, dont have their dark values resolved about postcss-jit-props

[mash-graz]

it puzzled me quite i while, before i finally found this issue and understood the reasons for the disappearance of my shadows.

do you already have an idea for nice solution to solve this issue?

it doesn't only affect the shadows, but also at least:

# grep --color -E 'var\(--[a-z0-9-]+\)' *css
# or
# rgrep -l -E 'var\(--[a-z0-9-]+\)' *css 

props.animations.css
props.borders.css
props.highlights.css
props.shadows.css

well -- as a simple workaround we can import the affected individual packs beside the JIT included props, but that doesn't look very convincing to me.

but in fact there are only a few property definitions needed to bypass the issue:

# rgrep -h -o --color -E 'var\(--[a-z0-9-]+\)' *css | sort | uniq

var(--ease-3)
var(--ease-in-out-3)
var(--ease-out-3)
var(--ease-out-5)
var(--ease-squish-2)
var(--highlight-color)
var(--highlight-size)
var(--radius-1)
var(--radius-2)
var(--radius-3)
var(--radius-4)
var(--radius-5)
var(--radius-6)
var(--shadow-color)
var(--shadow-strength)

adding this few definition by the postcss JIT plugin or providing a dedicated individual CSS pack for this purpose, would make the final CSS size smaller and definitely reduce the otherwise unavoidable troubles for end users.

how do think about this possible solutions?

[argyleink]

thanks mash-graz for the thoughts! i've updated the bug to reflect the problem space better. jit-props can resolve nested props but it doesnt resolve light AND dark props, just light ones. i need to devise a syntax, similar to @Keyframe animations, that let jit-props know to inject dark alt versions as well.

[mash-graz]

o.k. in this case it seems to affect only two code blocks:

/* highlights.css */

@media (--OSdark) {
    --highlight-color: hsl(0 0% 100% / 20%);
 }

/* shadows.css */

@media (--OSdark) {
  :where(html) {
    --shadow-strength: 25%;
    --shadow-color: 220 40% 2%;
  }
}

why shouldn't we add this few lines of CSS code all the time automatically by postcss-jit-props?

it's a nearly negligible amount of code compared to all these often unused definitions imported by open-props/normalize, which are unfortunately very hard to reduce on complex build systems like astro, where tools like PurgeCSS etc. do not work very reliable.

does this flaw also affect media queries and open-props substitution in CSS code added by the users?

[argyleink]

the data/json that's passed into jit-props needs to be able to specify a prop with multiple values in various contexts. it's a new syntax addition is really what needs to happen.

the easiest way to do it now would only solve dark mode:

{
  "--shadow-strength-@light": "1%",
  "--shadow-color-@light": "220 3% 15%",
  "--shadow-strength-@dark": "25%",
  "--shadow-color-@dark": "220 40% 2%"
}

usage in CSS:

.box {
  box-shadow: var(--shadow-1);
}

after jit-props processes:

:root {
  --shadow-strength: 25%;
  --shadow-color: 220 40% 2%;
  --shadow-1: 0 1px 2px -1px hsl(var(--shadow-color) / calc(var(--shadow-strength) + 9%));
}

@media (prefers-color-scheme: dark) {
  :root {
    --shadow-strength: 25%;
    --shadow-color: 220 40% 2%;
  }
}

that would make it work kinda like keyframes, not require a nested data structure, and only work for light/dark themes (not size media queries). which would be fine for open props, but doesnt solve the problem entirely.

to solve the whole thing, a syntax needs created that jit-props can read and intelligently grab values from the json. some sort of parse and point thing. but maybe no one needs that feature?

[argyleink]

actually, this bug was fixed a few commits ago, the nested props feature is g2g.
#11 where the dark/light props need worked out is where we should be directing chat!