It depends on your use case. Storing WGS84 coordinates as 32-bit floats can incur on errors of several meters. It might be good for your fitness tracking application, but not for serious GIS usage.
Case in point: many years ago I was working on some software to generate 3D models from drone pictures. The first step of the pipeline was to convert from WGS84 to ECEF (https://en.wikipedia.org/wiki/Earth-centered,_Earth-fixed_co...), an absolute Cartesian coordinate system. Well, it turns out that at the scales involved, 6.371 million meters, 32-bit floats have a precision of half a meter, so the resulting models were totally broken.
Isn't that more of using a float to represent the number? Would be akin to trying to represent .5. Which, if your goal is to represent decimals, you are best off not using floats.
Granted, just storing it as a 32 bit integer is probably difficult for most uses. BCD just isn't common for most programmers. (Or fixed point, in general.)
You should be able to do the calculations in fixed point, easily enough? Indeed, it used to be that most embedded systems would use fixed point due to lack of float hardware.
I would actually think fixed point would be beneficial for its accuracy being a bit more controlled than floating point is. Yes, you lose the range of floating point. But I just don't see how that is relevant for numbers that are constrained to +/- 180 by definition.
That all said, I cannot and do not argue against that it is faster to get going with basic float/doubles, due to how commonly those are supported in base libraries.
For gradients it definitely isn't unless you have the ability to do FRC dithering where the dither pattern changes every frame. The banding is very noticeable on a large enough screen.
LG just introduced a new 13 bit color TV... https://youtu.be/82InNlCqxlU it makes a difference in dark colors apparently. I can often still see banding on high end monitors.
Do I need that kind of precision in my CSS? Probably not. But for gradients, it seems helpful.
Yes. The claim that you don't need more than 3 decimal places is laughable. Your artificial design doesn't need decimal points. At all. You probably can do even better by ignoring the last 4 bits completely.
That said, the article is very interesting, and that claim applies on different contexts. It's just aimed at the wrong one.
It depends on the minifier (SVG optimizers do this too), but yes, they may reduce the precision of colors. I checked and esbuild will turn lab() into a hex color if possible.
lol, the website reminds me of tropes like the professional cleaner whose house is messy, the chef who eats instant noodles at home, or the haut couture fashion designer who only wears jeans and tees. The colour expert whose website is monochrome.
> The magic number to remember is the "Just Noticeable Difference" (JND). For dE00, JND is around 2.0. Below that, people struggle to tell two colours apart. Below 1.0, basically no one can.
Except for a tetrachromat. Specifically, a strong tetrachromat that has both four colour channels in the brain and a different frequency on the fourth cone.
Who are, admittedly, hella rare. Apparently there are less than a few dozen confirmed world-wide.
Ahhh, NASA numbers! My favourite, particularly in SVG files, and more recently in colours.
What is a NASA number?
Allegedly, within NASA, there is only a need for so many decimal places. If I can remember correctly, nine digits would get a spacecraft to land within a metre on the rock formerly known as the planet Pluto. So no need for that, unless you are going to 'occupy Pluto', building a few AI datacentres there.
In the context of SVG, usually it is icons that I encounter, where the artworker has exported something like a search icon, which is a circle and a line. These can be specified in SVG using integers, and single digit integers, if you really want, but let's make it two digits.
However, does the SVG file from the artworker have a viewbox containing a circle and a line? Nope. Instead you get one circle for the outer part of the circle in black and another smaller circle in white. Oh, and a line. The circles will be written as polygons with about two hundred vertices, with all vertices specified with NASA numbers (as I call them), typically six decimal places.
As a consequence, the file, which should be six lines of human readable code balloons to many kilobytes of nonsense. Yes, this can be put through SVGO but that will just remove some decimal places and make the file even less human readable.
As a developer, the simple file is great as the inevitable adjustments can be applied easily, maybe to make the icon bold or to adjust alignment within the viewbox. However, when given artworker files with NASA numbers, I then have to raise a ticket so that I can get the corrected file two weeks later from the guy sat in front of a massive Apple monitor with headphones welded on.
The reason for not using NASA numbers has nothing to do with bloat, as no optimisation will make up for the mountain of javascript the marketing guys have bundled into their Google Tag Manager, it has everything to do with efficient workflows.
Generally the customer does not care about fonts, colours and much else that designers fret over. If we went back to the 216 'web safe' colours of yesteryear (for CSS, not images), would anyone notice? If we could not load custom fonts, would most people notice? They might, but this would not prevent them from surfing the web.
I've always assumed minifiers were a kind of lossless compression. I guess this optimization makes it lossy? Even if we can't tell the difference between oklch(0.659432 0.304219 234.75238) and oklch(.659 .304 234.752) they're still different colors.
Very interesting article, and the color picker is exceptionally revealing. As for the challenge, it stopped working in Firefox after the first half dozen examples; but on Chromium I got a decent .0042 Fun!
This is an amazing deep dive into color difference measurements and how sensitive the math is. The idea that we really need to save characters - bytes - in CSS when we have so many web sites chewing through 49 MB with the enshitification of the web is hard to reconcile.
67 comments
Case in point: many years ago I was working on some software to generate 3D models from drone pictures. The first step of the pipeline was to convert from WGS84 to ECEF (https://en.wikipedia.org/wiki/Earth-centered,_Earth-fixed_co...), an absolute Cartesian coordinate system. Well, it turns out that at the scales involved, 6.371 million meters, 32-bit floats have a precision of half a meter, so the resulting models were totally broken.
Moving to 64-bit floats fixed this issue.
Granted, just storing it as a 32 bit integer is probably difficult for most uses. BCD just isn't common for most programmers. (Or fixed point, in general.)
But any kind of calculation will involve a great deal of trigonometry, square roots, and the like. It is just easier to use floating point. Examples:
https://en.wikipedia.org/wiki/Geographic_coordinate_conversi...
https://en.wikipedia.org/wiki/Vincenty%27s_formulae
https://gist.github.com/govert/1b373696c9a27ff4c72a
I would actually think fixed point would be beneficial for its accuracy being a bit more controlled than floating point is. Yes, you lose the range of floating point. But I just don't see how that is relevant for numbers that are constrained to +/- 180 by definition.
That all said, I cannot and do not argue against that it is faster to get going with basic float/doubles, due to how commonly those are supported in base libraries.
(It both is and isn't, depending on the use case, but I'm pretty sure nobody's design needs to make a difference between #123456 and #123457.)
Do I need that kind of precision in my CSS? Probably not. But for gradients, it seems helpful.
That said, the article is very interesting, and that claim applies on different contexts. It's just aimed at the wrong one.
Do CSS minifier really adjust the colors in the CSS files to get better compression rates or to reduce the number of rules in the CSS?
> The magic number to remember is the "Just Noticeable Difference" (JND). For dE00, JND is around 2.0. Below that, people struggle to tell two colours apart. Below 1.0, basically no one can.
Except for a tetrachromat. Specifically, a strong tetrachromat that has both four colour channels in the brain and a different frequency on the fourth cone.
Who are, admittedly, hella rare. Apparently there are less than a few dozen confirmed world-wide.
But they do exist.
What is a NASA number?
Allegedly, within NASA, there is only a need for so many decimal places. If I can remember correctly, nine digits would get a spacecraft to land within a metre on the rock formerly known as the planet Pluto. So no need for that, unless you are going to 'occupy Pluto', building a few AI datacentres there.
In the context of SVG, usually it is icons that I encounter, where the artworker has exported something like a search icon, which is a circle and a line. These can be specified in SVG using integers, and single digit integers, if you really want, but let's make it two digits.
However, does the SVG file from the artworker have a viewbox containing a circle and a line? Nope. Instead you get one circle for the outer part of the circle in black and another smaller circle in white. Oh, and a line. The circles will be written as polygons with about two hundred vertices, with all vertices specified with NASA numbers (as I call them), typically six decimal places.
As a consequence, the file, which should be six lines of human readable code balloons to many kilobytes of nonsense. Yes, this can be put through SVGO but that will just remove some decimal places and make the file even less human readable.
As a developer, the simple file is great as the inevitable adjustments can be applied easily, maybe to make the icon bold or to adjust alignment within the viewbox. However, when given artworker files with NASA numbers, I then have to raise a ticket so that I can get the corrected file two weeks later from the guy sat in front of a massive Apple monitor with headphones welded on.
The reason for not using NASA numbers has nothing to do with bloat, as no optimisation will make up for the mountain of javascript the marketing guys have bundled into their Google Tag Manager, it has everything to do with efficient workflows.
Generally the customer does not care about fonts, colours and much else that designers fret over. If we went back to the 216 'web safe' colours of yesteryear (for CSS, not images), would anyone notice? If we could not load custom fonts, would most people notice? They might, but this would not prevent them from surfing the web.
https://news.ycombinator.com/item?id=47390945