hide (prevent) more-info completely

[Mariusthvdb]

per the same by_X we now have.

consider this siren, for which I now have hidden both logbook and history:

clicking the icon opens the more-info:

which for my users is not much more relevant info (nothing at all I fact), while at the same time still showing the top right administrative icons

wouldnt it be a fine option, to completely disable the more-info?

( we would have to find a way how to get to the edit UI if we must, maybe flick a boolean or so indicating we temporarily disable the hide settings) but if not shown, it would be perfect for the average day user.

[elchininet]

wouldnt it be a fine option, to completely disable the more-info?

I don‘t think that is possible or at least that should not be something easy to achieve. More-info dialogs are opened by home assistant and it cannot be avoided. This is just a JavaScript plugin loaded in front-end not a integration. What we can do is just add styles, change properties of elements, but no more.

That is a question for Home Assistant front-enders.

[Mariusthvdb]

if I dont want a more-info in HA I use card-mod and set pointer-events: none

wouldnt that be a css we could add in the case of not wanting to show a more-info at all?

in this case it would need to be:

            card_mod:
              style:
                hui-generic-entity-row $: |
                  state-badge {
                    pointer-events: none;
                  }

to stop the interaction when on the icon, because

            card_mod:
              style: |
                :host {
                   pointer-events: none;
                }

would prevent interaction on the selector itself too....

[elchininet]

Card-mod is something that you add directly in the cards and as you have knowledge about in which place you are adding it, you target specific elements or rules to apply the styles to.

But in this case we are talking about a code that runs in a higher scope and doesn't have any knowledge about what you have in your dashboards (that could be native cards or custom ones) and doesn't have knowledge about the place in which the cards are located (they could be very deep in the DOM tree or appear when the user makes certain action). What you are proposing is to scan the whole DOM tree searching for fixed cards (and that list of cards will be rather very long). That will not be only huge in terms of performance but will also fail easily with custom set ups.

For those generic tasks, generic and flexible solutions like card-mod should be the path to take.

[Mariusthvdb]

cool, and agreed.

is good we have these card_mod examples mentioned. I might even add them to the readme or other examples in the docs, as it is relevant thinking

Ill close this discussion as is