Blink and WebKit are less sexy and use tetrasexagesimal a.k.a. 1/64 (https://trac.webkit.org/wiki/LayoutUnit). 1/60 was tried originally, but it was switched to 1/64 for performance and to avoid precision loss. The reason it's faster is interesting: floating point values are also stored as number with a base-2 exponent, so to convert to/from floats, you can use shifts instead of needing division. The differences between 1/60 and 1/64 were important 10 years ago but are pretty minor now.
Thanks for that. I was very confused as to why the value was about 7% larger than 16,777,216 (2²⁴), and not exactly that.
But assuming a binary representation (!) having the subdivisions be slightly fewer than a power of 2 (60 being slighly less than 64) means that the whole number limit will be slightly over a power of two, meaning that 60 × 17,895,697 should be a power of 2 (give or take a bit of rounding).
And if you do the multiplication, it's 1,073,741,820, which is... huh. 2³⁰ (- 4).
Why not 2³¹ or 2³²? Looks like they could at least double the CSS length limit there, even while continuing to allow negative lengths.
Edit: As we can see from the parent-linked source on line 36, there is:
# define nscoord_MAX nscoord((1 << 30) - 1)
which confirms the limit, but doesn't say why 30 is used instead of 31.
Thanks for that. I was very confused as to why the value was about 7% larger than 16,777,216 (2²⁴), and not exactly that.
But assuming a binary representation (!) having the subdivisions be slightly fewer than a power of 2 (60 being slighly less than 64) means that the whole number limit will be slightly over a power of two, meaning that 60 × 17,895,697 should be a power of 2 (give or take a bit of rounding).
And if you do the multiplication, it's 1,073,741,820, which is... huh. 2³⁰ (- 4).
Why not 2³¹ or 2³²? Looks like they could at least double the CSS length limit there, even while continuing to allow negative lengths.
Edit: As we can see from the parent-linked source on line 36, there is:
which confirms the limit, but doesn't say why 30 is used instead of 31.Edit2: Info in the commit message at https://github.com/mozilla/gecko-dev/commit/e632c1393ebedfda...
Makes sense.