I am trying to keep the images pure so I can change the text etc. without editing the image everytime.
I managed to create the background bar by using type: icon without an icon.
I wanted to use ‘title’ in the icon element but that does not seem to work. Maybe I am missing something?
Because I would need an image (required) and I would need an entity who’s label I can use. Meaning, I would have to manually create an entity just so I can display a label. Actually I would need to create a bunch of entities as I need different labels.
Imho creating a bunch of entities for service purpose - not a big deal.
Alternatively you may use a markdown card: create a decluttering template for a card w/o background and with required font-size, then use it in 100 places.
Sorry, found the information when I googled for css styling, so I removed the question before you answered.
But what I hae not fixed yet:
I would like the main image to have a tap_action.
Tap_action for the picture of picture elements card is not supported. So I figured I would simply use my target image in ‘type: image’.
But that leaves me with the issue of defining the (invisible) background image of the picture elements card.
I wanted to use a small “dummy” image to reduce the loading time etc. But I cannot figure out how to scale it to size.
This works, but it loads my alex_half_jpg twice, which is a waste of resources.
If I wanted to change the picture card image to e.g. a 1x1px image, how could I scale it to the size of the ‘type: image’ image?
I noticed that the layout looks quite different in my browser compared to the companion app. So it seems that the layout is not being applied correclty even though I am specifying everything in relative values (%) rather than absolute (px).
Is this a known issue or am I defining something wrongly?
Strange. Has an issue been raised on github on this? Relative positions should be identical on all devices. I am terrible at living with things
Especially since the whole purpose of the picture elements card is to create something “pretty”
I doubt that rounding is an issue given the extreme variations.
And if you look at my example above, the shift is not only horizontal but also vertical. So at least the base line should be identical given the identical vertical percentage used.
Scaling should also not be the issue given again that there is a baseline shift. So at least the base line should be identical. Scaling would cause a problem towards the top, not the bottom, IMHO.
Yes, but if you define the base line at 0% from bottom then, unless there are multiple problems aside from the actual scaling, the object should be placed at the lowest possible point and then scaled upwards and sidewards from there.
So a horizontal shift would be explained by scaling problems. But a shift downwards if you are already at the lowest point (bottom: 0%), would not be a simple scaling problem. It would be a problem of the initial positioning.
And if the base line is e.g. at pixel 10 from bottom on one display and pixel 50 from bottom at another (each representing 0%), then all objects should be placed at pixel 10 from bottom or pixel 50 from bottom.
You should not see some at pixel 45, some 50 and some 55. Rounding cannot result in different values if the factor is a constant and the rounding is applied to the same variable.
Is it possible to somehow use the horizontal-stack card in picture elements? It seems like it is possible to use custom cards so I am not sure why an integrated card should be any different from a custom card.
Thomas Lovén’s custom hui-element card is usually the way to get around this limitation, but I’ve not tried it myself with a picture elements card, so can’t 100% guarantee it will work in this case. But worth a try I would think.