I’m currently trying to rework my custom Web Components to also work with Aura. Some have typical variants like success, info, warning, error, etc. and the --aura-accent-* style properties seemed like the way to go here.
My naive assumption was that I would just use the --aura-accent-* properties (like --aura-accent-border-color, --aura-accent-surface, etc.) and could change them by just setting
--aura-accent-color-light/dark on a component (via the component’s Aura-specific CSS based on the theme-attribute).
But it turns out I would have to also redeclare all accent properties that I want to use, even if it’s just copy pasted lines like --aura-accent-color: light-dark(var(--aura-accent-color-light),var(--aura-accent-color-dark));.
Setting some common themes like info, error etc. already properly updates --aura-accent-color*. But that still doesn’t update any of the other accent-related style properties. That only happens for the <html> element, the official Vaadin components and some specific classes. And I don’t see a way to apply those unless I set an Aura-specific class in the Web Component itself, which ideally should be theme-neutral. Also these classes have certain semantics and also trigger other selectors, so I would have to pick one that actually suits my use case. I suppose setting a class that’s simply not used in Lumo doesn’t really hurt, but it nonetheless makes me think that I’m probably doing it wrong.
Yeah, you encountered one of the limitations of CSS custom properties and Aura. Like you noticed, many of the color property values are evaluated only on elements that match the selectors you linked to in the Aura colors.css file.
The only way for custom components to use those same computed colors is to match one of the selectors in that list. The most applicable is probably the .aura-accent-color class, but I see how it feels odd to use that in a component that should be reusable across themes.
One solution might be that we add the [theme] selector to that list, which would be more theme-agnostic (confusingly, and no pun intended). I’ve just been hesitant in doing that, because I haven’t looked into the performance impact it might have. It’s probably negligible, as the list of selectors already matched a lot of elements any way, but we should check it regardless.
Eventually I hope that all browsers add support for CSS @function, and we can use that for the derived colors which decouples the computation from any selectors.
Btw, this same limitation applies to the surface colors.
Yeah the idea of adding [theme] to the selector list sounds iffy to me. AND we might refactor theme variants to use classnames anyway, which would kind of defeat the point.
CSS @function, could probably be supported in V27 (i.e. Dec 2027 or so) earliest, unless Safari and Firefox surprise us all by supporting it very soon.
Oh, but wait: How about container style queries?
If we bump minimum Safari version to 18 in V26, we could use them.
It’s nowhere near as convenient as @function, but it might be possible to force re-evaluation of derived properties on any element.
I haven’t considered container queries at all in this context. Can you elaborate?
I have not thought this through at all 
but I was thinking something along the lines of:
Any element where a property like --aura-accent-color-light is set would automatically update --aura-accent-color to use it, through something like
@container style(--aura-accent-color-light) or style(--aura-accent-color-dark) {
--aura-accent-color: light-dark(var(--aura-accent-color-light), var(--aura-accent-color-dark));
}
(This may very well be a brainfart, but I wanted to put it out here just in case it helps)
Ah but yeah that would only work on child elements, not the element you apply the property to 
In terms of workarounds I could imagine a lot worse than simply adding the aura-accent-color class. I could even take the extra step and add some sort of theme detection (ThemeDetectionMixin seems like a good start for that) and really only add the attribute for aura, but that seems hardly worth the effort.
So far this works perfectly fine and there’s always the chance to rework later when new options are available.
Thank you :)