is that an input datetime?
Yes. It is.
with that same theme, what does a input_select look like and an input_text?
There is no white there (only in the dropdown-box, but there the same in chrome, … The differnce is only for date time.
yep, I can’t do any testing where I am. It’ll have to wait, need access to a config
1 Like
I can confirm the odd energy panel details issue. inputs I can still see though,
as my history/logbook panels, they show fine. I posted a suggestion in History page does not load - #5 by Mariusthvdb to test a bit, reducing the recorded entities
And yes, out of the box, dark_mode is terrible when you have carefully set themes… so be sure not to use it 
offten a right click in inspector will reveal the theme color code though, so you can adapt in your theme. ( had that eg with the quickbar, and a simple adjustment in my themes fixed that)
Not urgent. I lived now with an ugly work-around for months, so I can wait.
IT’s not dark more. It is only a dark theme.
See above. A theme with only dark background color and the problem is there.
well, the issue you linked mentions dark_mode, so thats why I tested it. My screenshot is not dark_mode, but using a dark theme, (Dark blue for reference sake).
What exactly is your issue with those? You can change anything to anything, probably not an issue (as in bug), but just a tweaking thing
tbh, I find the input.date_time entities not very friendly on a touch screen anyways, this when I added these clickable buttons of the GitHub - GeorgeSG/lovelace-time-picker-card: 🕰️ Time Picker Card for Home Assistant's Lovelace UI
See above.
To make it more crisp. Set only a theme with
ha-card-background: '#2E2E2E'
and nothing more. Only the above. And then you have on mobile safari the white boxes.
where you dont have them in e.g. chrome, where it looks this way:
That’s the problem. And because of this, I named it bug, because same settings in theme should lead to same look in chrome and mobile safari (more or less at least).
Just give me a hint or theme variable, how to set the white on these input buttons to another color, which works for mobile Safari.
If someone is able to separate this discussion from this thread, please go ahead, as it is higly off topic.
var(--paper-input-container-shared-input-style_-_background)
Just was able to inspect the element. Not sure if it will work as safari is not rendering it with that property set with the default dark mode.
I’ll have to get back to you, I have access to a mac somewhere and it needs to be inspected on that. Either way, I’m seeing what you’re seeing. Nothing to do with darkmode.
No, this is what has been tried here as well. Result.
During searching I found another equal issue which have been closed yesterday with regards to the old one.
Isn’t there any chance that someone from the frontend devs picks up such 3-month-old untouched issue. The difference between webkit and other browser are there and (from my point of view) should be solved in the frontend. Of course, the problem was introduced in mobile webkit (as it started with 15.1) without changing of HA, most probably that it is not handling transparent or problems in inheriting, but there are a lot of such things already in frontend in css, this is only another one to solve.
nd BTW, this variable on top is used for other things as well, which are not background and with using this you are see this, e.g. no default/info texts in chrome
compared to
That’s what I said with ugly work arounds, which never solves the issue.
See, what Marius wrote. We are waiting since summer last year. 
Of course. See above.
That was the starting point. Didn’t want to discuss the several problems here in this thread and only wanted to second the problem, that frontend issues seem to be unmaintained.
Really don’t know, how to get the core devs again into it or to priritze bugfixing over changing the UI, esp. if the topic of the year is streamlining. A (again) working UI is for me the most important topic in streamlining. But most probably the Safari users can only live with it.
1 Like
Yes, and this is what I’m saying is a feature request. Splitting that attribute up into separate theme variables is a feature request.
The value not working properly is a bug. 2 separate things. Anwyas, as I said in my other post, I’m seeing your issue however I need to inspect the element on a Safari device, which I don’t have access to atm.
1 Like
same here on a rtsp stream
And look at that, it’s fixed. Patience is key
# Input Colors
input-ink-color: rgba(200, 200, 202) # Text
input-label-ink-color: rgba(200, 200, 202) # Mini-Info-Label
input-fill-color: rgba(40, 40, 40) # Background Color
input-dropdown-icon-color: rgba(161, 161, 161) # Icon (Left side)
input-hover-line-color: rgba(3, 169, 244) # Highlight color
input-outlined-hover-border-color: rgba(3, 169, 244) # Border Highlight color
input-idle-line-color: rgba(200, 200, 202) # Bottom line color
input-outlined-idle-border-color: rgba(3, 169, 244) #outline color
input-disabled-line-color: rgba(200, 200, 202)
input-disabled-fill-color: rgba(127, 132, 142)
input-disabled-ink-color: rgba(200, 200, 202)
input-outlined-disabled-border-color: rgba(127, 132, 142)
Mobile (iOS)
Desktop (chrome)
Yes, you are right. After changing the library the old problems are gone (I will close the ancious github issues), but new are there: How to style the :
style the what