Life is too short to design for Internet Explorer.
It works with Firefox, MS Edge and Chrome (on Windows 10).
Not sure if it will work with browsers available for XP.
I don't have access to old or new Apples or iPads.
Live is too short for anything but Linux! 
I did a bit cleanup in CSS and mirrored one so it may be clearer now what it takes to.
Still not perfect solution I'd guess but closer.
4 Likes
Very nice 
Small feedback, I noticed that the needle on the left is not properly centred at the bottom so it reads 1 degree more than the gauge on the right.
Also I guess you reused element names ? As I cannot have clock temp example on same flow as these.
I did look to see if I could find anything but I'm afraid its well above my capabilities.
Keep up the good work, it keeps me inspired.
Does not reproduce for me, Can you show ??
Here they are all in one card. Can't see any problems.
(a bit changed the quarter's small window placement rules to get alignment and sizes correct for different sizes)
regular-quarter-and-clock.json (74.2 KB)
2 Likes
The two needles are clearly aligned with each other - rounding error on the tick rotation maybe?
Ok. It goes into category "still not perfect solution".
1 Like
I assumed you meant clip-path is not supported by Internet Explorer?
But at least for me, neither the Node-Red editor nor Dashboard work at all on Interent Explorer, just a blank page.
Unless it's different for everyone else, it seems IE incompatibility is no reason not to use clip-path.
Well There is many more things which does not work for IE but your question was about the clip path and that I knew without looking can-i-use. There is a lot more what is not supported, like CSS variables and custom properties and so on.
It is for modern browsers for sure.
Some improvements for the quarter version element placement (should be much more accurate)
And little bonus - the zones
hontnipi-gauge-advanced-improved.json (67.6 KB)
4 Likes
Looking good, as ever. 
One thing though, when I import your flow, my clock has no hour ticks. (same with the last version you posted too). Well, they are present but all stacked up at 9:00
You may be have somewhere and active ui_template with another version of CSS?
Try to debug the major tick in the clock with browser developer tool. See if class is correctly added and the rule is not affected by something.
This is the only version of the gauges on this computer, because I've previously been surprised by CSS from another tab.
The rotation CSS for hour ticks:
.g-tick.clock {
transform: rotate(calc(calc(360deg / var(--ga-tick-count)) * var(--ga-tick) - calc(calc(360deg / var(--ga-tick-count)) +270deg)));
}
If I change it to
.g-tick.clock {
transform: rotate(calc(90deg + var(--ga-tick) * 360deg/var(--ga-tick-count)));
}
then the ticks do show. (I think tick 1 shows up at the 12:00 position which is probably not right)
Tick 1 is at 9 o'clock if original (latest should be same) CSS is used
You are on Firefox. And true. Some kind of issue with FF. The computed transform is none. Strange.
And issue found
.g-tick.clock {
transform: rotate(calc(calc(360deg / var(--ga-tick-count)) * var(--ga-tick) - calc(calc(360deg / var(--ga-tick-count)) + 270deg)));
}
The last +270 was without the space. FF does not like.
1 Like
Yes Firefox 92 on WIndows 10.
Does transform: rotate(calc(-30deg + var(--ga-tick) * 360deg/var(--ga-tick-count))); work in your browser?
(-30deg so the first tick is at 9:00, or 0deg for 1st at 10:00)
It does not matter where the tick is. (as long it is somewhere we are used to have the hour tick of the clock) There is no more dependencies but the logic where you define the side by numbers.
Yes that's why I started with 90.
I was thinking of colouring 12, 3, 6 & 9 red, so it would make sense for them to be --ga-tick:3 etc.
I guess that makes the start of the formula 60deg. I'd better try it...
