Can't override Open-Props custom property
I've been using Open-Props in my Svelte projects recently. I've tried overriding --shadow-color and noticed that I'm not able to. Here is my code:
I've looked at Open-Props' stackblitz playgrounds and noticed I can't override the color there either.
Dev tools show it should be getting used.
It's not Svelte's fault because I tried doing this in a raw codepen with no success.
This issue persists across browsers (Firefox Dev, Chrome Canary, Arc)
What am I doing wrong?
93 Replies
In my dev tools it seems like this override is working with the open-props style being crossed out
However when I edit this crossed-out style then that actually makes changes to my shadow's color (tested on Chrome and Arc)
it kinda feels like that the sub-values are being interpreted as compile type
I don't understand
Can you elaborate?
when svelte generates the css, it seems that nested
var and calc are calculated before the generation
This is in the SASS + Open-Props stackblitz playground
that's the original code, not the compiled code
still doesn't work
from my terrible understanding, it should work
So Svelte probably isn't at fault here, if anything maybe it's Vite
try using !important
by the way, try setting the shadow color in the html element
before the code is compiled
tried on a raw codepen, still nothing
doesn't work
im out of ideas then
the documentation for this is below hot steamy summer-time milky dumpster juice
https://open-props.style/#shadows <-- nothing about the shadow color
you can override it I'm sure of that, it's just a css variable
that's not the final result that the browser presents
modified demo from Adam Argyle, somehow works here
https://stackblitz.com/edit/open-props-light-only?file=index.css
here is the unmodified version
basically, it's re-writing the entire shadow definition, not changing the color
that's like rebuilding the entire house because you want to rotate a slice of bread
but hey, it's a valid approach
wait you're right, if I remove that
--shadow-5 declaration the shadow goes back to the default colorexactly
why does it work like that? it makes no sense to me
even the dev tools are confused
well, compare the value that the browser uses with the value that's in that css
the browser just uses the variable
what i saw in some stackblitz examples wasn't that
and based on the color and alignment, that's not the element inspector
it is
just Chrome Canary
looks weird
idk if normal Chrome has the theming etc
nah, it's just white
anyway, it uses the variable and if I modify that original variable then the color gets changed
bruh...
it makes no sense
is that a svelte example?
just a codepen
then you're comparing onions and apples
what?
it should work in a codepen first and foremost
your original problem was svelte + open props
does codepen support svelte?
but it turns out it doesn't even work outside of svelte so that's what we should focus on first
but I'm out of ideas
im out of ideas too
the documentation doesn't talk about it, so, i will assume that it isn't a supported case (which should be)
but Adam Argyle himself made that demo where he did it and that works somehow by redeclaring the style
which demo?
the demo re-defines everything
yes I know, but this still doesn't make sense
can you send your example?
Which one?
this is the entire codepen code
that's not a comparable example
you're not using vite
doesn't matter though it should still be working
it does matter
vite compiles the css
as I said we should first figure out why this doesn't work in a normal codepen
alright, send the link then
look at the css
it seems that the css is compiled without that variable
then change the default --shadow-color variable which open-props provides (there's a 2nd one if you use dark mode)
it uses the variable, nothing gets compiled
something bizarre is going on
this is the css that should be applying in the browser
I don't think this even is an open-props problem
I think this is just a problem with my understanding of CSS
i think it's a chrome problem
firefox works just fine
this doesn't work, the shadow should be blue
you're right
I think the main issue is that
--shadow-6 gets computed from the global --shadow-color and not the local oneit sounds like some sort of optimization to avoid too deep nesting
And there seems to be no other fix than to redefine the
--shadow-6 property in my button selector
Which sucks because that property is way too longi wouldn't worry about the size of it
I mean it's just very impractical
To redefine that entire property each time I want a custom shadow color
it is very impractical
My final solution is to just redeclare the shadow properties in a universal selector
Works fine
put it in the
:root
it's a lot fewer re-calculations
if :root doesn't work, use htmlno, that's the entire problem, the color won't update because
--shadow-6 gets computed inside :root instead of on a per-element basis
@Kevin if you haven't already, perhaps you could make a short video about this topic, since this is the first time I've encountered such a problem and honestly I'm still not sure what EXACTLY is going on and it's really difficult to find any information on this matter onlinethat's why you go down to
html
then body
instead of putting it everywhereit won't work that way,
--shadow-6 needs to be re-declared for every element which also wants to change --shadow-color since --shadow-6 is derived from --shadow-color, so if you don't redeclare --shadow-6 then it will just use the old --shadow-color valueyou're right
https://jsfiddle.net/0cxhyt2k/ <-- i tested it
Edit fiddle - JSFiddle - Code Playground
Test your JavaScript, CSS, HTML or CoffeeScript online with JSFiddle code editor.
This is a good article on the issue, and also one of the solutions is
*, where Chris says it's not really an option because of the performance implicationsWhat article are you mentioning here?
Chris Coyier
CSS-Tricks
The Big Gotcha With Custom Properties | CSS-Tricks
I've seen this confuse more than a handful of people recently, including myself, so I'm making sure it's written down.
Oh, thanks a lot :)
I'll read it right away
So all the fixes this article mentions are ok for some use-cases, but for me redeclaring an entire property for a shadow is too bothersome, since those can get quite long, maybe I could use solution #2 and comma-separate the selectors, but that still isn't as nice as using
*, do you know of any other solutions which could fix this problem? Maybe even a pre-processor of some sort would do the job?Nope, its just one of the limitations around how custom properties are computed.
Well, a Sass or Less variable would work the way you want, I think. As long as you don't mind using their variables instead of a custom property
Err, I think. Worth quickly testing anyway
Oh, a Sass variable you say? I'll definitely check that out
Thank you
Unfortunately doesn't work
Well I guess I'll need to write my own pre-processor if I want both a good DX and a good UX haha
Yeah, same limitation there. Goes to where it's defined, and uses that version.
I'm just gonna make a pre-processor, never made one, but I'll try
it works
super crude and not that optimized but also should be better than using a universal selector