Card-mod v4 updated the method of application cover near 100% of standard Home Assistant Frontend cards while still supporting custom cards not utilising the modern hui-card container for child cards.
Further examples that may assist other users understanding special cases are welcome. Please submit a PR.
- patch/patching = card_mod is running injected code into the element class
- application/applying = card_mod applies a card_mod object to element, usually in the shadowRoot, and children as per selectors
- ignore/ignoring = card_mod element patching code takes no action when running at the element level
- Using
tilecard as an example. - Does not apply card-mod at card level (
tile) as you would need many different CSS rules which would make theming a nightmare. - Base CSS styles via
:host { }or card styles viaha-card { }.
hui-card β card-mod v4 patches here
β³ tile β this is `:host` for card-mod and where card-mod `class` is set
β³ shadowRoot β card-mod applies here, `ha-card` is in light DOM
β³ ha-card β card-mod v4 also patches here but ignores due to known standard structure- button-card has a
divbeforeha-card, thus not a standard card structure - As card (button-card) is still patched you can use CSS vars via
:host { }. - Likewise, you could use yaml selector paths. See comments below.
- Legacy ha-card patch and appliation is at ha-card level where
ha-card { }will work.
hui-card β card-mod v4 patches here
β³ button-card β this is `:host` for card-mod and where card-mod `class` is set
β³ shadowRoot β card-mod v4 applies here
β³div
β³ ha-card β card-mod v4 patches and applies here, does not ignore as it is not a standard structure. card-mod class is also be set here.
β³ shadowRoot- As host card is still patched you could apply CSS vars via
:host { }. - Likewise, you could use yaml selector paths. See comments below.
- Legacy ha-card patch and apply for loaded card is at ha-card level where
ha-card { }will work.
hui-card β card-mod v4 patches here
β³ streamline-card β this is `:host` for card-mod and where card-mod `class` is set for the host custom card from host card's card_mod config
β³ shadowRoot β card-mod v4 applies here for host custom card
β³ tile
β³ shadowRoot
β³ ha-card β card-mod v4 patches and applies here for card loaded by custom card, does not ignore as it is not a standard structure. card-mod class is set here for card loaded by host custom card from the loaded card's card_mod config
β³ shadowRoot- Custom cards that are wrappers like
streamlined-cardcould adopt wrapping in each card inhui-card. This would give all benfits of users who could then includevisibilityconditions or even tempating the newdisabledconfig option. These only work 100% when usinghui-cardas a wrapper. This is whatexpander-cardnow does and has 100% success. NOTE: If you see anything like a history card not updating on first load, that is due to not taking this appaorach card-mod-cardtheme variable applies to newhui-cardpatching and the legacyha-cardpatching.- For situations where you have cards loaded in a standard way, and also by a custom card like layout-card, you can use due CSS selestors to target both in your themes
- When you know there is a parent
hui-cardpatch you can adjust your themes to match. e.g. for streamlined-card, the example below will work for patching fromhui-card, the*matching the unknown card type (to card-mod) in the streamlined-card structure.
The examples show card_mod applied to a card. Similar would also work for themes.
:host(.my-class) ha-card selector for cards loaded by Frontend. ha-card.myclass for custom cards using a divergent structure, or for cards loaded by custom cards.
card_mod:
style: |
:host(.my-class) ha-card,
ha-card.myclass {
background-color: red !important;
}card_mod:
style:
"* $": |
ha-card {
--card-background-color: red;
}OR
card_mod:
style:
"* $ ha-card": |
:host {
--card-background-color: red;
}