Post

We’ve entered this phase of the blog post.

2 reposts119 likes

Only happens when deployed, works perfectly locally. That plus the waits fixing means there’s a race somewhere I just dunno where.

Events to the rescue. The timeouts are arbitrary. You can’t trust 50ms. You need to know when something is ready to start the animation. You need to know when the animation is ready and do the next thing.

There's a reason universities are renaming their Computer Studies degrees as Bachelor of Googling StackOverflow. Sometimes, the only answer is someone else's unanswered question.

I know it's generally "bad", but rather than this kind of hopeful timing hacks, generally it's a lot more stable to force a sync reflow (e.g. just getting document.body.offsetWidth would do). Still mostly a hack, but at least it doesn't rely on some magic timing and doesn't take 3 frames.

It might do, testing this was highly frustrating because I couldn’t reproduce it locally. So I gave it a lot of wiggle room to reduce the amount of times I have to wait for GitHub pages to deploy my site.

When rendering an SVG to a canvas on Safari there's a 1/10 chance the canvas will not render the images embedded in the SVG, UNLESS you first draw that SVG with an <img> tag visible within the viewport and ensure a mouse interaction happens on it. AAAAAAAAAAAAAAAAAAAAAAA

`z-index` and `scale()` ensure the cursor is hovering over the image (as long as it is within the browser viewport), and `top` change ensures reflow to cause the mouse move event to fire. If you remove anything from this code, it fails to fix the bug.

The animations consistently didn’t play for me, but only on Firefox and only after the site been deployed. I couldn’t reproduce it locally, despite the code being identical. Leads me to believe it’s a timing problem, though I never did try network slowness emulation in the dev tools 🤔