Poll: Should UIX provide an option to keep the native more-info styling?

[Kanecaine]

Background

Since UIX 7.7.0, dashboard theme overrides are also applied to more-info dialogs.

I understand the reasoning behind this, but I think there is an important distinction between using a theme as a dashboard theme and using it as the Home Assistant main theme.

I have always used themes at dashboard level. For a long time I wasn't even aware that themes could be used as the main HA theme. In fact, I intentionally prefer the rest of Home Assistant — including more-info dialogs — to retain the normal native HA appearance.

Why this matters

I tested this with two themes:

iOS Themes — many issues in more-info
Graphite — much better, but even its dark variants still show several differences

The pattern was remarkably consistent: existing theme variables are used by newer HA/Web Awesome components inside more-info, although the theme was originally designed for the dashboard context.

More details about this can be found in this discussion.

Of course, these themes could potentially be updated. But that assumes that theme authors consider the more-info-dialog as part of the scope of their dashboard themes. I'm not sure that is necessarily the intended use case for many existing themes.

The question

Would it make sense for UIX to provide an explicit opt-out, for example:

Prevent UIX from styling more-info dialogs

This would simply leave the native Home Assistant more-info styling untouched. It would not need to introduce another mechanism for selecting a different theme.

Alternatively to a integration setting, maybe this could be implemented as a theme-level keyword that is only interpreted by UIX.

I'm mainly interested in whether other users see this distinction the same way:

Should a dashboard theme automatically style more-info-dialogs, or should users be able to keep the native HA appearance for dialogs?

Please react with 👍 if you would like UIX to provide such an option. If you disagree, please react with 👎.

[Mariusthvdb]

tbh, I dont get what you are saying...
please can you explain with a short example in your theme? You are talking about 'overrides', but, setting a theme in HA is not overriding anything, it is just using the Frontend and its options to set another color or border-radius or whatever to the non default theme settings in HA. Its by design of Frontend to apply themes, with available theme tokens.

when you set HA tokens in your (regular) theme, they are applied everywhere HA decides to apply them, and that has nothing to do with UIX.

now if you start using UIX theming you can target specific elements, like uix-more-info, and only that. Is that what you are referring to?

if yes, please remember that you can still style per dashboard, or per view card even, and have a main theme set. UIX is all equipped to allow you to do so.

long story short: please add an example.... ;)

and yes, you need to change / adapt the tokens in downloaded themes like you mention, many authors of those themes dont do that, and if HA frontend changes, you're out of luck. but again, that is a bug in the themes no longer being up to date with HA itself

bottom-line answer to the poll:
No.
if a user doesnt want to change native more-info styling, then dont (change the tokens that style the more-info).
it's up to the user.
Nothing to be done by UIX.

[Kanecaine]

Hi thanks for your reply, did you read the mentioned discussion here?

#500

Please let me know, if i need to further clarify what i already tried to describe there :)

[Mariusthvdb]

yes, but there I just see some screenshots, not a yaml example of the applied tokens for the more-info.
just adapt to the correct tokens and your set

[Kanecaine]

Thanks, I think the important point is what changed with UIX 7.7.0.

Since 7.7.0, UIX applies the complete set of CSS variable definitions of the dashboard theme to the more-info dialog's inline style. As a result, the dialog is no longer using the normal Home Assistant theme values, but effectively gets the dashboard theme's complete set of variables.

This is where the problem occurs, especially with dark themes. The native more-info dialog can end up looking quite broken because theme variables which are perfectly valid for the dashboard are also consumed by components inside more-info.

This is how the more-info dialog looks when i am using UIX and the iOS theme without any further customization:

For example, the iOS theme intentionally defines:

secondary-background-color: rgba(25, 25, 25, 0.9)

This works correctly for the dashboard. However, inside more-info, a newer HA button uses:

background: var(--secondary-background-color);

so that button becomes almost black. In the normal HA more-info dialog, without the dashboard theme applied, the same variable is:

secondary-background-color: #e5e5e5

and the button looks correct.

This is just one example. The screenshot shows the overall result when no overrides are applied: different parts of the dialog end up with different, unintended backgrounds and surfaces, while some text also uses a colour with insufficient contrast. I found many similar cases involving cards, form fields, dropdowns, the YAML editor, hover states and icons.

In each case, the theme value itself is not necessarily wrong — it is simply being used in a different context than the theme was originally designed for.

That's why I don't think the solution is necessarily to "fix" the theme. For users like me, the desired behaviour is simply to use the theme for the dashboard while leaving the native Home Assistant more-info styling untouched.

As a workaround, I spent quite a lot of time creating UIX-specific overrides to restore the native appearance of the dialog. The result is usable, but it essentially means recreating parts of the native HA theme inside UIX:

uix-more-info-yaml: |
  "ha-more-info-details $": |
    ha-yaml-editor {
      --codemirror-property: #905 !important;
    }
  
  .: |
    :host {
      color: #141414 !important;
    }
  
    :host * {
      --primary-text-color: #141414 !important;
      --secondary-text-color: #5e5e5e !important;
      --secondary-background-color: #e5e5e5 !important;
      --rgb-secondary-text-color: 114, 114, 114 !important;
      --disabled-text-color: #999999 !important;
  
      --primary-color: #009ac7 !important;
      --primary-background-color: #fafafa !important;
      --card-background-color: #fff !important;
  
      --ha-dialog-surface-background: #fff !important;
      --ha-dialog-surface-backdrop-filter: none !important;
  
      --ha-card-background: #fff !important;
      --ha-card-border-width: 1px !important;
      --ha-card-border-radius: var(--ha-border-radius-lg) !important;
  
      --ha-color-form-background: var(--ha-color-neutral-95) !important;
      --ha-color-form-background-hover: var(--ha-color-neutral-90) !important;
      --ha-color-on-neutral-normal: var(--ha-color-neutral-40) !important;
  
      --wa-color-neutral-fill-normal: var(--ha-color-fill-neutral-normal-resting) !important;
      --wa-color-surface-default: #fff !important;
      --wa-color-surface-raised: #fff !important;
      --wa-color-text-normal: #141414 !important;
      --wa-color-text-quiet: #666666 !important;
  
      --wa-form-control-background-color: #fff !important;
      --wa-form-control-value-color: #141414 !important;
      --wa-form-control-placeholder-color: #666666 !important;
  
      --state-icon-color: #44739e !important;
      --state-icon-active-color: #FDD835 !important;
      --state-icon-unavailable-color: #999999 !important;
  
      --code-editor-background-color: #fff !important;
    }

I hope this clarifies the two points I am trying to make:

• Using UIX with some existing themes, especially dark themes, can result in a broken-looking more-info dialog.
• Fixing this requires additional customization: either the theme maintainer has to extend the theme to support the more-info context, or, as in my case, the user has to add UIX-specific overrides to restore the native Home Assistant appearance.

The latter is technically possible, but it requires a level of CSS, Shadow DOM and DevTools knowledge that I simply don't have — I only managed to do this with the help of ChatGPT.

[dcapslock]

As noted earlier, since you are only applying these to a dashboard you are not seeing the theme's issues. If you applied these globally then you would see the more-info issues always. So as we agreed that should really be fixed. Allowing for an option to not apply to more-info is really masking the theme issues.

[Kanecaine]

You are right. I just tested the iOS theme as the main theme, and in that case the problem does not occur at all — the more-info dialogs are styled consistently.

I'll investigate this further on my side and get back to you once I understand what is causing the difference.

Sorry for the possible confusion, and thanks for pointing this out.

[Mariusthvdb]

desired behaviour is simply to use the theme for the dashboard while leaving the native Home Assistant more-info styling untouched

I believe this to be the crux of the matter. Or rephrase, probably your misunderstanding of how things work in HA (please dont get me wrong, not pointing a finger or any negative connotation..)

Once you'll read up on the matter in the official documentation and the (sometimes obscure changes in HA frontend... I'll admit to that) you will see that those more-info dialogs as just part of the full frontend, and not separate in the default theme.

if you check my gists (see bio), where I link the exact files in Frontend that contain the style tokens, you'll see which applies to which.

[Kanecaine]

Okay, maybe I've actually misunderstood something so far, or maybe I have a different take on it. But I've now been able to narrow down the problem significantly, and I'd like to hear your thoughts on it.

I have now found a very simple way to reproduce the behaviour without using any specific third-party theme. I created a minimal theme containing only one variable:

uix-test:
  primary-text-color: "red"

Then I use:

Main Theme: default (or not set)
Dashboard Theme: uix-test

I then select a native wa-input directly in the dashboard (I used the code input of an alarm-panel) and run these three console commands on the wa-input element:

getComputedStyle($0).getPropertyValue("--primary-text-color")
getComputedStyle($0).getPropertyValue("--wa-form-control-value-color")
getComputedStyle($0).color

Next, I repeated the same commands after opening a more-info dialog from within the dashboard and selecting a wa-input inside the more-info dialog. I used the name field of the entity settings.

This is the result:

Token	Dashboard wa-input	wa-input inside UIX more-info
--primary-text-color	red	red
--wa-form-control-value-color	red	#141414
color	rgb(255, 0, 0)	rgb(20, 20, 20)

So the "same" wa-input, with the same dashboard theme, behaves differently depending on whether it is rendered directly in the dashboard or inside the more-info dialog using uix.

I also tested the control case with the minimal theme applied globally as the main theme:

Main Theme: uix-test
Dashboard Theme: not set or also uix-test

In that case both the dashboard wa-input and the more-info wa-input return:

Token	wa-input
--primary-text-color	red
--wa-form-control-value-color	red
color	rgb(255, 0, 0)

This seems to rule out the specific iOS theme, dark themes, or any particular theme variable as the cause. The behaviour can be reproduced with a theme containing literally just one variable.

What I find difficult to explain is why --primary-text-color is correctly red inside the UIX more-info context, while --wa-form-control-value-color remains #141414 — the value from the default/main-theme context.

In the normal dashboard context, the a wa-input gets red for both variables.

So, unless I am misunderstanding something fundamental about how these CSS custom properties are supposed to work, this looks like an inconsistency somewhere in the interaction between the dashboard theme, UIX's more-info handling and the HA/WA theme variables.

You don't even need to use console commands to see the problem. All you need to do is use a minimal theme with red text and then look for places where the text is not red. With input fields like wa-input, it's especially noticeable that they adopt the red text color in some places but not in others.

At the very least, this doesn't seem consistent to me. I'm curious whether you see something here that I am missing.

---

Finally, here are two images from the test mentioned using just a minimal theme with only one line defining a red primary text color:

• on the left: a wa-input in the dashboard with correctly red text (the asterisks)
• on the right: a wa-input in the entity settings of the more-info dialog with black text that should be red too

[Mariusthvdb]

Main Theme: default (or not set)
Dashboard Theme: uix-test

please explain what you do to set that 'Dashboard theme.'

note that just calling a theme, 'uix-test' doesnt make it have anything to do with UIX....

its just called uix-test, and has 1 token set. all other tokens would remain as defined in default HA styling, default theme, or, not setting a theme at all.

fwiw, you could have named it 'apple' an it would still behave identically

[Kanecaine]

please explain what you do to set that 'Dashboard theme.'

Sure: I enter edit mode of the dashboard and click the pen to edit a view. There i set the theme for this view.

note that just calling a theme, 'uix-test' doesnt make it have anything to do with UIX....

I know that. I justed used that name for the minimal theme example. What i am talking about ist this feature introduced with 7.7.0. With that the active theme is used by uix to style the more info dialog (as i understand that correctly).

has 1 token set. all other tokens would remain as defined in default HA styling, default theme, or, not setting a theme at all.

Exactly, but the thing is that this 1 token (in the example) isn't applied consistently, as my example was meant to illustrate. With a “proper" (meaning complete) theme, this leads to the effects mentioned at the beginning: a mix of styles that are applied and those that aren't.

Perhaps I should point out, to avoid further confusion, that this has nothing to do with the styling by uix. It’s not about a uix style, but rather the uix-function that applies all styles (token) from the active theme to ha-adaptive-dialog.

[Kanecaine]

Thanks for testing it out. That's correct so far, but please in the second image click on the settings icon and take a look at a wa-input element (the entity name, for example). I didn't choose this element at random; it demonstrates the behavior for --primary-text-color in this simple example. See also my screenshots above.

[Mariusthvdb]

yep its controlled by --wa-form-control-value-color which should be var(--primary-text-color) ....

https://github.com/home-assistant/frontend/blob/c0b296a5a2a3cf5381cb3ff36126537bdeed6fb2/src/resources/theme/color/wa.globals.ts#L70

[Mariusthvdb]

if one does this

uix-test:
  primary-text-color: red
  wa-form-control-value-color: var(--primary-text-color)

the more-info shows that

I admit I am surprised that is needed though, as the console shows it should be inherited.

Now were getting somewhere, it took me a bit....

I can confirm that setting the uix-test theme as main theme via frontend.set_theme does apply to that same more-info, and there is a remarkable difference with the above (group /speach)

Id say that might be a bug indeed..

Are you saying that without UIX this doesnt happen (I mean, default main theme, and test theme to the view does set the primary-color in the more-info)?

[Mariusthvdb]

answering myself: no, without UIX loaded the issue remains the same.

see: default main theme, test theme to the view

Id say that is a Frontend issue that should be filed there

[Kanecaine]

Thank you very much for taking the time to reproduce this and look into it in such detail. I think we have finally reached a common understanding of what is actually happening, even if we may still have different views on the conclusion.

Are you saying that without UIX this doesnt happen (I mean, default main theme, and test theme to the view does set the primary-color in the more-info)

and later you said:

answering myself: no, without UIX loaded the issue remains the same.

I have to disagree with this part, and I think I can now demonstrate why. The important distinction is that setting the main theme to default is not the same as disabling UIX. For this test I completely disabled the UIX integration. I then used:

Main Theme: default / not set
View Theme: the minimal theme containing only:

uix-test:
  primary-text-color: "red"

With UIX completely disabled, opening the native Home Assistant more-info dialog does not apply the view theme to it. The text in the dialog remains in the normal Home Assistant styling — there is no red text at all.

1. uix disabled ("Durch Benutzer deaktiviert" translates to "deactivated by user") - i had to restart home assistant after deactivating

2. main theme set to default

3. view theme set to the minimal theme example

4. no red text in more-info

And this is different from the situation we tested before, where UIX was still enabled and only the main theme had been set to default. With UIX enabled, UIX takes the active (view) theme and applies its tokens to the more-info context. This is where the inconsistency appears and because of that i suppose it is not a HA frontend issue.

I think this also explains why we were talking past each other earlier. Home Assistant itself does not appear to apply a view theme to the native more-info dialog. UIX does this as an additional behaviour. Personally, I actually like the fact that HA keeps the view theme separate from the global frontend appearance here — but I understand that others may have a different preference.

Last point: the --primary-text-color / --wa-form-control-value-color example is only one token and one ui element (wa-input). I have found many other affected areas as well, including cards, form fields, the YAML view of entity attributes, hover states and icons that are appearing inappropriately in more-info. So this is clearly not just a matter of adding one missing variable to a theme.

[dcapslock]

On review I see this is an issue with how UIX applies a theme and elements that inherit from standard browser elements like input and dialog will not have theme vars correctly applied as they need to be redefined to be valid.

As UIX allows theme override in many places, this will be a general UIX theme application fix. Once this is done then there will be no issues with more-info on a view with override theme. This will mean no need for any option to not style more-info as the suggestion was due to dealing with the issue. As such I will close this poll and make an issue. I will update the original discussion with the issue once created.

Thank you @Kanecaine for your patience and also @Mariusthvdb for your input.