Ok, so I was wrong about this being Grid card problem, at least that I can’t seem to reproduce that issue, however I am finding that the ‘features’ option does not work via the UI.
Yet I can add the ‘features’ with YAML.
Since that ha-slider migration the below code stopped working and I corrected it with the new parameters, everything works except for the “pointer-events: none;”
Old code:
card_mod:
style:
hui-generic-entity-row:
$: |
:host {
--paper-slider-active-color: var(--disabled-text-color);
--paper-slider-knob-color: var(--disabled-text-color);
--paper-slider-container-color: var(--disabled-text-color);
--paper-item-icon-color: var(--disabled-text-color);
color: var(--disabled-text-color);
pointer-events: none;
}
New code:
card_mod:
style:
hui-generic-entity-row:
$: |
:host {
--md-slider-active-track-color: var(--disabled-text-color);
--md-slider-inactive-track-color: var(--disabled-text-color);
--md-slider-handle-color: var(--disabled-text-color);
--paper-item-icon-color: var(--disabled-text-color);
color: var(--disabled-text-color);
pointer-events: none;
}
Can somebody enlighten me how should the “pointer-events: none” be handled? Thanks
HI Paul,
Been trying to figure out all changed variables there, but run into a bit of problem with that 
current theme variables are:
paper-slider-knob-color
paper-slider-knob-start-color
paper-slider-pin-color
paper-slider-active-color
paper-slider-container-color
paper-slider-secondary-color
paper-slider-disabled-active-color
paper-slider-disabled-secondary-color
paper-slider-bar-color
and I can not find the direct replacement for all of these in the doc you linked as that only lists:
--md-slider-active-track-color
--md-slider-active-track-shape
--md-slider-inactive-track-color
--md-slider-inactive-track-shape
--md-slider-handle-color
--md-slider-handle-shape
would appreciate it if you could find a moment to help and create a direct replacement instruction for those?
This is fixed in the 2023.11.2 update. Thank you!
I use this GitHub - j-a-n/lovelace-wallpanel: 🖼️ Wall panel mode and photo screensaver for your Home Assistant Dashboards in my old IPad with guided access and it is great!
You have all tokens list in the code using the « all token » link in the page I provided (below the table). Just prefix them with —md-slider-.
Also, these variables are not officially supported by HA and will never be because we don’t want to be stuck with a library. So it can (will certainly) break in the future.
thanks I didnt spot that before
md-slider-active-track-color: green
md-slider-inactive-track-color: yellow
md-slider-focus-handle-color: black
md-slider-pressed-handle-color: white
md-slider-handle-color: pink
md-slider-hover-handle-color: orange
md-slider-handle-shadow-color: red
md-slider-label-container-color: grey
md-slider-label-text-color: purple
seem to be working. However, I can not find the correct variables for the slider container itself as they are nit mentioned in that linked page?
that doesnt sound really user-friendly… why make the move now then…
it’s not supported and will certainly break again.
As theming is supposed to be the way the endusers can/should customize their frontend (opposed to using all custom cards), why not make that theming more robust going forward?
Material etc controls imho are not a part of HA, they tend to be changed/upgraded/…, HA should not provide a persistent “proxy” theme CSS variables. This is completely up to users to maintain their styles. Sad but true.
We will not move away from Material. So theorically it should continue to work.
But if Material developers change the variables or deprecate the library (like they did for the previous slider), it will break 
That’s why we don’t officially support it.
1 Like
This is my automation:
alias: Peter supermarkt
description: Peter supermarkt
trigger:
- platform: zone
entity_id: person.mobiel_peter
zone: zone.aldi
event: enter
- platform: zone
entity_id: person.mobiel_peter
zone: zone.jumbo
event: enter
condition: []
action:
- service: notify.mobile_app_sm_g781b
data:
message: >-
There {% if states('todo.boodschappen') | int < 2 %} is{%else%}
are{%endif%} {{ states('todo.boodschappen')}} {% if
states('todo.boodschappen') | int < 2 %} product{%else%}
producten{%endif%} left on the grocery list.
title: Peter is at the supermarket
data:
actions:
- action: URI
title: Open grocery list
uri: /lovelace/boodschappen
mode: single
2 Likes
I didn’t ask for creating a proxy for any library thing at all, I asked to make theming more robust…
Proxy for library? I wrote “proxy for CSS vars”.
correct, I edited my post.
What I was saying is, please HA, provide the user with a stable/robust way of theming, that won’t break continuously.
Theming is a core HA provided technique to customize our frontends, so making that robust is high on the wishlist…
1 Like
Assume there is some (material or whatever) control (slider or whatever).
The control consists of X elements; there are Y vars to style it - var_1 … var_Y.
When I said “proxy for CSS vars” - here is what I meant:
HA could have proxy vars (and maintain them):
persistent_var_1 = var_1
…
persistent_var_Y = var_Y
And a user uses these proxy vars - and does not depend on the actual vars.
But one day number of var_1 … var_Y may change - and also a purpose of these vars may change, and a structure of the control may change.
So - the realistic way is NOT to officially expose the control’s vars to a user. It is up to the user to maintain his styling.
edit:
i need multiple restarts after (almost every) HA update to have it running all normal again. is this normal?
yes, you describe the way it is currently done. Not the ideal situation going forward though. Nor a very mature one.
My point is this is rather sub-optimal.
We should not try to describe the solution ourselves (frontend dev’s are pro’s and way more capable than we are to think of a robust way to improve this) but leave it to the pro’s.
remember the state-color issue? It was fixed because dev team heard the communities needs and frustrations of eternal changes, implemented a new way for theme variables, and now it’s working perfectly.
If something internal is changed, it wont hurt the frontend of thousands of users, because it is handled in the frontend itself, and the user can be agnostic to those internal changes.
I would hope something like that could be implemented for the theming variables used in HA Frontend. (this release the sliders, what is it going to be in the next).
Expose generic elements to the user so these can be used in themes, but handle changes in whatever library/ccs/element/etc behind those away from the end-user.
2 Likes
What exactly does not work after an update but works after multiple restarts? Never had such issues and it doesn’t sound logical as the update already implies a restart of HA
1 Like
I must admit. I have now rolled back to 2023.10 and going to stay there for a longer period of time. At least 3-4 months. Every update for a long time now have included new bugs and something that is different and not working optimal. Sorry to say but the updates here are getting rushed out and are not quality assured.
3 Likes
I feel the same. The update to 2023.11 has been a royal pain in the ass for me in regards to automations.
I have over a hundred automations affected. I am slowly rebuilding everything, but keep shaking my head over the fact that even if you disable the problem device or entity the automation remains “unavailable” This just doesn’t make any sense to me. For example if you have a device that dies, then it kills your automation, which could have a dozen or so other entries in it that do work. You should just be able to disable the problem entry and the automation should continue to run…
Hopefully there will be a change in future updates so that you can just disable the problem portion and continue on.
Earlier this year I decided to skip the .0 releases and wait for .1. I have had basically no problems since then (the only real debacle I’ve seen is related to colors/themes breaking). Some problems will occur as part of the nature inherent to growing a large piece of software; expect to provide minimal adjustments.
This release I waited a week before upgrading because I knew I’d have to redo my shopping list customizations to work with the new to-do list functionality. There’s some small script updates I need to perform soon relating to the changes they made to forecast entities earlier this year that will soon be removed.
I am thankful for the all of the hard work that many people put into this project to advance the functionality every month, and look forward to every new release.