What is the 'user theme', and why can certain CSS variables only be set there?

Configuration Frontend
1

I just learned that there’s certain CSS variables (e.g. dialog-backdrop-filter) that only work when specified in the ‘user theme’, but not in the dashboard-specified theme. (I discovered it through this off-hand comment on a browser_mod issue.)
From what I could find, there isn’t really a user theme, is there? There’s just a default theme you can choose and which is probably stored in your browser instance, so it isn’t even sticky to your user account across devices.

I find that very surprising and confusing, and would like to learn more about what the reason for this differentiation is, and what other variables this ‘rule’(?) applies to.

I don’t know where to look. Home Assistant frontend - Home Assistant doesn’t really mention the ‘user theme’ and its intricacies at all.

Background: I’ve created a theme, which I’m using on a single dashboard. It’s really designed for this dashboard only. It’s not intended to be used across HA and really makes the general UI look broken, so I do not intend to select this as my ‘default theme’ across HA.

I just use it to factor out common definitions so I don’t need to repeat them over and over. This discovery makes me question whether that’s a viable approach. I now also suspect that this is why I’ve been going crazy unsuccessfully trying to set certain things with card_mod, specifically for browser_mod.popup dialogs.

Why do certain variables only work in ‘user themes’? Or was that statement I found incorrect? (I could seemingly reproduce this, however – but maybe I’m misinterpreting my unstable test results.)

Is there a better place to do dashboard-specific theming (e.g. setting CSS variables) than in a one-off theme?

2

I think the reference to user themes are to what can be user defined in the theme.yaml file.
Some CSS settings added to this file do not seem to take effect though and those are then said to not be in the user theme.

3

User theme = theme created by a user, not attached to some particular user.
It is a per-client thing.

To use common parts of card-mod-theming across different themes - use !include (per a keyword).

If some variable declared in a theme does not affect on UI - probably this variable is not “themeable” because it is set inside some UI element.

4

That’s not what I’m describing.

Here’s an example:

  1. Define primary-background-color and dialog-backdrop-filter in a new theme, e.g. themes/css-var-test-theme.yaml. (Register in your configuration.yaml as needed.)
css-var-test-theme:
  ha-card-background: green
  primary-background-color: hotpink
  dialog-backdrop-filter: blur(30px) brightness(0.5)
  1. Create a new YAML dashboard. Set:
views:
  - title: Test Dashboard
    theme: css-var-test-theme    # <-- the dashboard theme!!!
    cards:
      - type: tile
        entity: light.some_light_or_other_test_device

Note that the dashboard activates the theme!

  1. Restart HA to load the new theme.

  2. Open the dashboard. Notice the atrocious colors on card and background. However, open the ‘more-info’ dialog and take note of the backdrop filter not being applied!

  3. Now navigate to your profile page and set the same theme, that the dashboard already activated, again!

  4. Reload the dashboard with the doubly-activated-theme and open the ‘more-info’ dialog on your tile. Only with the theme selected twice, the dialog-backdrop-filter takes effect!

WTF. I don’t find this documented anywhere.

5

More-info is not a part of this view. So the theme is not applied.

6

That’s highly unintuitve and not documented.

Please try taking a newcomer’s perspective on this. Do you think anything of what you said — and the behavior I described above — is how they would expect the system to behave?

That there’s two (simultaneous!) ways to set a dashboard’s theme (one stored on the dashboard, and one in the browser — none in the user profile, btw.!), and that one affects dialogs (because they are not part of “the view” – duh!) and one that doesn’t.

No mention of the more-info dialogs not being part of the views on the views page either.

7

There is 2 places where you can place your suggestions:

  1. “Feature requests” section of Community.
  2. GitHub for HA documentation.

I merely described you a current implementation.
For me, the fact that more-info is not a part of a view is obvious. Views are created a customized by a user (ofc I am not talking about auto-generated dashboards), more-info is a system window without a possibility to customize (ofc some customization is possible by 3rd party plugins - but not by system settings).

Btw, some stock cards allow to set a theme; and obviously more-info windows displayed after tapping an entity on some card with a defined theme will not “inherit” this theme - otherwise we will see differently styled more-info windows which is nonsense.