You can assign a specific theme to a view, but not a dashboard. This means items that exist (technically) outside the view do not get the theming applied.
Specifically, that means any dialogs, including both more-info popups, as well as custom browser-mod popups, do not receive the view’s theming. The consequence is that if you use popups, the theme setting on a view is rather useless, and instead you need to set a theme in the user’s browser session.
Worst of all, I find that really underdocumented and very unintuitive for new users. If you’re not really making use of the dashboard views (which I’m not) and only ever have a single view on your dashboard, you might not even fully notice that a theme is set for a view, and not a dashboard.
Here’s an example:
(Unfortunately, I’m away from home and my HA became unreachable, so I’m writing this down from memory and couldn’t test it.)
So, you expect that more-info opened from dashboard_1 should differ from more-info opened from dashboard_2 and from more-info opened from Settings->Entities, right?
As an end-user, that’s absolutely what I would expect, yes!
If I open a more-info modal popup from dashboard_1, I would expect it to be styled the same way as the tile card on dashboard_1 that opened it.
Even more importantly (as I don’t use more-info, personally), if I have a card on my dashboard that opens a popup window (using browser-mod, because that’s unfortunately not supported natively by HA), and the popup contains the same card, they should obviously be styled the same!
It’s very unintuitive that a card on a dashboard is styled one way, but when I move it into one of my modals (opened using a button on the same dashboard!) it changes its theming. That took me hours to figure out…
If the more-info is opened from Settings > Entities, or any other non-dashboard UI element, or an unthemed dashboard, then it should inherit the theme from the user’s default theme. That’s also very obvious to me. After all, that’s why it’s called the “default theme”.
Consider more-info as a “system window” which is managed by a “system-wide-for-this-client” theme.
If you disagree - then think either about renaming this WTH - or creating a new separated WTH.
Sorry, I’m not following. What’s off with the title of the WTH?
You can’t assign a theme to a dashboard, only to a view, correct? I find that very WTH, as my intuition would be to give the dashboard a theme. What’s the purpose of using different themes on each view of the same dashboard? I can’t think of a use case, and the docs don’t either.
My personal expectation (admittedly, I have no data to prove that) would be that most people who want to assign a specific theme to a dashboard want to do so on the dashboard level, not on the view level. Furthermore, my assumption is that they expect this to apply to everything that happens on or from that dashboard — including any and all popups that arise from interactions with the dashboard/view.
(You’ve changed your post, so this reply has become a bit of a non sequitur. I responded to your edited question in a new post below.)
You can’t assign a theme to a dashboard, only to a view, correct? I find that very WTH, as my intuition would be to give the dashboard a theme. What’s the purpose of using different themes on each view of the same dashboard? I can’t think of a use case, and the docs don’t either.
My personal expectation (admittedly, I have no data to prove that) would be that most people who want to assign a specific theme to a dashboard want to do so on the dashboard level, not on the view level. Furthermore, my assumption is that they expect this to apply to everything that happens on or from that dashboard — including any and all popups that arise from interactions with the dashboard/view.
I understand a reason of having a GLOBAL theme:
I want to have same look everywhere - in views, in more-info, in Settings, Dev tools, …
And I understand a reason of having a theme for a particular CARD:
Assume this card should have a red background + cyan text, I created a theme with these 2 variables → now THIS particular card got this look.
(ofc this can be done by card-mod - but this is a 3rd party solution)
I see no use-case for a theme for a view.
But may be someone needs & uses it.
Same for a dashboard (which may be not supported).
Conclusion: if you need a styled more-info - use a global theme since more-info is a system thing.
Good question. It is to separate design and content.
In my case, one dashboard it is optimized to run on a specific tablet mounted to the wall. It is optimized for screen size and resolution of that one device. There’s a certain background, a specific color scheme and also board-specific customizations of certain cards using card-mod.
The wall display is running that single dashboard in full-screen and never anything else, also never any other page of HA.
I want that entire dashboard to be using a specific design. I could set up these design rules on each card, but then I’d have to repeat the same card-mod setup over and over.
There’s multiple (browser-mod) popups, all of which use a certain design, which would need to be repeated on each one.
If I ever want to make changes to the design, I need to do them across the entire set of YAML files as well.
Think of my setup like HTML and CSS. The dashboard YAML files (I’m using lots of !includes for structure and hierarchy) are the HTML, defining what to show. The theme is the CSS, declaring what they are supposed to look like.
The theme is optimized for this dashboard alone. I do not want to use it for my menu, my Settings, etc. In fact, it makes those almost impossible to read (think white font on yellow background). It’s really only for that one dashboard. Which is why I’d like to assign it to that dashboard.
You said you are using yaml, so reusing a code is not a problem, you mentioned “include” yourself.
That is why people use mediaqueries to set a particular look for a particular client.
In fact, there are no ready stock solutions to limit a dashboard for a particular client.
There are solutions, discussing them will be off-topic here.
Anyway - you can set a custom global theme on this client, so this dashboard (which is “only used on this client”) will be properly themed.
From what I’ve seen you comment on the forum, you’re well aware of YAML and it’s limitations, aren’t you? You cannot even include-and-override or include-and-extend properly. So if I understand you correctly that you think I should separate style and content by applying a card_mod rule to every single card — I think you know very well that this isn’t feasible for any slighly more complex dashboard.
I never said anything about needing to limit a dashboard to a particular client. Just that this client is only ever using a single dashboard.
Those aren’t the same things.
That’s my current workaround, but it’s quite frustrating. First of all, you cannot set a default theme for a user, only for a browser session, so this always requires getting into that browser session during setup.
Second, it means you cannot really review or test this dashboard with another browser session (default theme), because then it doesn’t render right.
More importantly, all of this took me many hours to troubleshoot, identify and understand — including with your help in conversations on earlier forum posts about this topic.
I can work around it now. It’s frustrating, but I’m accomplishing what I’m looking for. But I think this is highly unintuitive and I’m trying to save others from the same troubles.
It is, to this day, the aspect of HA that I put by far the most hours into wrapping my head around. And therefore my #1 WTH.
This is not what I suggested.
In fact, in that my particular sentence I did not propose you any particular solution.
My general proposals are posted in card-mod thread (1st post → link at the bottom → reuse code).
Sorry, I am not getting this, never faced any difficulties.
I honestly see no connection between your last post & the thread’s title - probably you faced issues which I never did.
But really appreciate your intention to help other users.
In short, what I am doing for diff clients:
card-mod + card-mod-themes + external js (where possible) - with relative units & mediaqueries.
different layout for different mediaqueries.
(for a particular small & weak client) Separate dashboard with SIMPLE stock cards, other dashboards are not accessible on this client.