Inconsistency with defining colors in a default theme

[ildar170975]

Checklist

• I have updated to the latest available Home Assistant version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.

Describe the issue you are experiencing

Since 2022.12.0, colors in a default theme are defined like "255,255,255" - instead of "rgb(255,255,255)" (or "#ffffff") as it was before.
And this happened to SOME colors (probably to the newly added vars) - check this file:
https://github.com/home-assistant/frontend/blob/f1393e5f00690287a78665faf88ca6145d4aaf48/src/resources/ha-style.ts

example 1:

example 2:

Why colors are defined in different ways?

All variables must have "traditional" versions (i.e. defined as "rgb(255,255,255)" or "#ffffff") which are EXPOSED for external use - for instance, in custom plugins.

Describe the behavior you expected

as above

Steps to reproduce the issue

as above

What version of Home Assistant Core has the issue?

2022.12.0

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue with?

Chrome 108.0.5359.95

Which operating system are you using to run this browser?

Win10x64

State of relevant entities

No response

Problem-relevant frontend configuration

No response

Javascript errors shown in your browser console/inspector

No response

Additional information

No response

[piitaya]

Many colors already use this type of color. It allow to add opacity to color in CSS. For example : --rgb-primary-text-color

If you define custom-color: "#xxxxxx" in your themes, it will be automatically create 2 css variables:

--custom-color: #xxxxxx;
--rgb-custom-color: rrr, ggg, bbb;

[ildar170975]

It allow to add opacity to color in CSS

Opacity was supported earlier too:

--some_var: rgba(r,g,b,a)

It is STILL supported:

test_new_colors_theme:
  ha-card-background: rgb(0,255,0,0.2)

w/o opacity:

with opacity:

So, need of opacity cannot be a reason of moving to "255,255,255".

[piitaya]

In some components, we need to apply opacity to a css variable.

color: rgba(var(--some_var));

You can not do that if your var is not in CSS format.

Example of component : tile card

Why are you opposed to this? It's just internal, not user facing thing because you can declare the variable in a hexa format.

[ildar170975]

we need to apply opacity to a css variable

Why not parsing "rgba(r,g,b,a)" into "r,g,b,a" before using?
You can even parse HEX values into "r,g,b,a".
The way you specified "r,g,b,a" vars w/o supporting their "traditional" versions - cannot be EASILY used by other people who try to customize their UI. They will have to redesign their cards/themes to the "r,g,b,a" way.

---

If you define custom-color: "#xxxxxx" in your themes, it will be automatically create 2 css variables:

--custom-color: #xxxxxx;
--rgb-custom-color: rrr, ggg, bbb;

No, I do not see it working.
Consider this theme:

test_new_colors_theme:
  rgb-state-binary-sensor-alerting-color: 0,255,0

and this card with "heat" sensor:

type: entities
entities:
  - type: section
    label: alerted
  - entity: binary_sensor.testing_device_class_heat
    name: default
  - entity: binary_sensor.testing_device_class_heat
    name: styled (--rgb-state)
    card_mod:
      style: |
        :host {
          --rgb-state-binary-sensor-alerting-color: 255,128,0;
        }
  - entity: binary_sensor.testing_device_class_heat
    name: styled (--state) - FAILED
    card_mod:
      style: |
        :host {
          --state-binary-sensor-color: #ff0000;
        }
state_color: true

As we can see - since the var was defined as "r,g,b,a" in a theme - I cannot use it's "traditional" version to re-define a HEX color.

OK, let's define the color as HEX in a theme:

test_new_colors_theme:
  state-binary-sensor-color: #00ffff

and this card with "connectivity" sensor:

type: entities
entities:
  - type: section
    label: normal
  - entity: binary_sensor.testing_device_class_connectivity
    name: default
  - entity: binary_sensor.testing_device_class_connectivity
    name: styled (--rgb-state)
    card_mod:
      style: |
        :host {
          --rgb-state-binary-sensor-color: 255,128,0;
        }
  - entity: binary_sensor.testing_device_class_connectivity
    name: styled (--state) - FAILED
    card_mod:
      style: |
        :host {
          --state-binary-sensor-color: #ff0000;
        }
state_color: true

Here I can re-define a color by using "--rgb-state" var with "r,g,b" value.
But I cannot re-define a color by using "--state" var with HEX value.
Also, the style is NOT initially defined in the theme since it seems to not accepting HEX.
Means - the "traditional version" cannot be used either to define a theme or (again) to re-define a color.

This is an answer to your question:

Why are you opposed to this? It's just internal, not user facing thing because you can declare the variable in a hexa format.

[piitaya]

You're not using theme but card_mod third party card.

If you define this in your theme, it works :

test_new_colors_theme:
   state-binary-sensor-alerting-color: "#ff0000"

[ildar170975]

You're not using theme but card_mod third party card.

Check again my example - the 2nd card, the 1st row - there is NO card-mod here, and the style CANNOT be defined in a theme.

[ildar170975]

f you define this in your theme, it works :

test_new_colors_theme:
   state-binary-sensor-alerting-color: 0,255,0

No, it does not:

test_new_colors_theme:
  state-binary-sensor-alerting-color: 0,255,0

Probably because you suggest to use "r,g,b" value to "state-binary-sensor-alerting-color" instead of "rgb-state-binary-sensor-alerting-color".

[piitaya]

I fixed my previous message using hexa code.

[ildar170975]

If you define this in your theme, it works :

test_new_colors_theme:
   state-binary-sensor-alerting-color: "#ff0000"

I see - I should have put HEX value into "`", then the theme is set:

but still this variable cannot be used in card-mod or injected into DOM by any other way.

Seems that allowing to use variables by custom plugins is not what is appreciated.
This is a breaking change.

[piitaya]

Use --rgb-state-binary-sensor-color for card_mod.
We never supported and will never supported card_mod overrides. a custom card that inject codes into card.
We did this conversion for themes. If you want this for card_mod create a PR on card_mod repo.

[ildar170975]

In some components, we need to apply opacity to a css variable.

OK, you do not want to allow to use vars externally.

But I did not get your feedback regarding "why r,g,b instead of rgb(r,g,b)".
You said "opacity" - I said "you can achieve same by rgb() or HEX".

[piitaya]

Feel free to do a PR to replace rgb by hex if you find a solution for the tile card icon background color and slider background color.

[ildar170975]

Feel free to do a PR to replace rgb by hex if you find a solution for the tile card icon background color and slider background color.

Improving one card (very nice and powerful w/o any doubts) should not be harmful for other cases (((.
If you need separate components r,g,b,a - they may be parsed from "rgba(r,g,b,a)" value.
For HEX "#00ffffff" it is similar - "white with 0 alpha".

[michalk-k]

In some components, we need to apply opacity to a css variable.

Don't get this one. Maybe I'm lost in your reasoning.
Using color names, hex colors or rgb/rgba functions is css compliant.

Why do you need to refuse usage of css compliant expressions for css?