[css-values-4] Explicitly undefine CSS numeric precision in general

[tabatkins]

Leaving aside the more specific issue of calculation trees in #4551, CSS numeric precision can vary greatly, both across and within implementations: layout-related values are measured in some integer number of layout-units (either 1/60, 1/64, or 1/100 of a px in current impls); others are stored as f32 or f64; some integers have funky ranges so they can be packed into bitfields efficiently with other values.

I don't anticipate this changing, either by impls aligning with each other or impls using a single numeric type across all their numeric values. We've tried in the past to give explicit ranges for allowed precision, but couldn't settle on values then either. I suggest we just explicitly state that numeric width/precision is undefined in CSS.

[Crissov]

Indeed, the only practical way to enforce a more uniform or at least higher precision for absolute <length> values would probably be a new unit much smaller than px. That idea has been rejected before, though.

1px	1pt	1twip*	1q	1um*
60	80	4	~56.693	~0.22677
64	85.3…	4.26…	~60,472	~0.24189
95.25	127	6.35	90	0.36
100	133.3…	6.6…	~94,488	~0.37795
105.83…	141.1…	7.05…	100	0.4
127	169.3…	8.46…	120	0.48
150	200	10	~113.39	~0.56693
190.5	254	12.7	180	0.72
225	300	15	~212.598	~0.85039
264.583…	352.7…	17.638…	250	1
381	508	25.4	360	1.44

• twip: twentieth of a point, 20twip = 1pt, 15twip = 1px
• um: micrometer, 1000um = 1mm, 250um = 1q

[tabatkins]

Going much smaller than a px wouldn't help either. Impls won't want to switch to a substantially smaller LayoutUnit, because that would reduce the maximum length they can represent; right now an s32 LayoutUnit's upper range is between 1e7px and 1e8px (exact value depends on the LU->px conversion in use). Going up a few more bits will reduce that max by 1/4 or 1/8; maybe ok, but pushing it on reasonably supportable max page lengths.

Plus, the reasoning for the current LayoutUnits aren't compatible: FF chose 60 per px to give lots of good divisors (can easily represent 1/2, 1/3, 1/4, 1/5, 1/6, 1/10, 1/12, 1/15, 1/20, 1/30 of a px); Chrome chose 64 for easy binary conversion to/from px; old-Edge chose 100 for easy human readability and a reasonable amount of good divisors.

[AmeliaBR]

FYI, SVG requires single precision floats, with doubles recommended for intermediary calculations.

I know we don't have universal support for this, though. Things get wonky when you use small decimals or large values, even when a float should be able to represent the differences precisely.