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.
There's a great children's history book titled "This Bridge Will Not Be Gray" by Dave Eggers that goes into the early days of the color choice. The bridge was shipped over from east coast metal works in orange, so it was not gray to begin with. The choice to keep it orange involved some public support so I think it is unlikely that it was ever painted gray, even temporarily.
Yes, my thinking is that if it ever was gray there would have been so much outcry that it is bound to show up in search results and be mentioned by any outlines of the bridge’s history.
This article is just about acceleration and stacking is not introduced. WebKit's architecture ties together the concepts of stacking and acceleration. A positive effect is that it will be quite easy to support stacking in SVG with this work.
A negative of joining the concepts of stacking and acceleration is that it is difficult to get acceleration without introducing paint order bugs where the accelerated content starts painting above non-accelerated content.
There is some discussion of the differences in the two editions in https://news.ycombinator.com/item?id=4665466 as well as the reviews on Amazon. I am going to give the updated version a try.
SVG filter support in Chromium is actively being worked on, primarily led by an incredible engineer at Opera (fs@opera.com). This work has been ongoing for almost a year and should complete in Q4. Please star https://crbug.com/109224 for updates (stars also help prioritization).
Thanks for the link. This CDC guidance is basically the tl;dr of the actionable parts of the medium article. The CDC guidance is:
* Maintain good social distance (about 6 feet). This is very important in preventing the spread of COVID-19.
* Wash your hands often with soap and water. If soap and water are not available, use a hand sanitizer that contains at least 60% alcohol.
* Routinely clean and disinfect frequently touched surfaces.
* Cover your mouth and nose with a mask when around others.
A small difference between the medium article and the CDC guidance is the order of importance, particularly as the weather gets colder in the US. The medium article argues #4 (masks) and #1 (distance) are more important than #2 (hand washing) and #3 (cleaning). The order on the CDC site is probably more of an artifact of how the guidance evolved rather than the relative importance (the wayback machine shows the mask bullet was added June 1st: https://web.archive.org/web/*/https://www.cdc.gov/coronaviru...).
See A Satellite Tonight (https://james.darpinian.com/satellites) is a nice tool for finding these. I have a young kid and it's been fun heading out at night and spotting these.
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.
If you're interested, the code is at https://github.com/mozilla/gecko-dev/blob/d36cf98aa85f24ceef... and https://source.chromium.org/chromium/chromium/src/+/main:thi...