This page seems to capture scrolling in a weird way: if you scroll over the middle of the page, when the page moves such that the cursor ends up over one of the rendered image, the scrolling immediately stops, and the continued scrolling motion starts zooming the rendered image instead.
Yeah, sorry for that, 100% agree on the scrolling UX point. I finished the article at 11 pm, so didn't have time to write custom UX for the embeds. I added a border for now to make the embeds stand out more.
The site is an exercise for me in getting things out sooner than later, because I tend to struggle with perfectionism quite a lot [*]. After my 111 days of daily writing I'll probably port it back to https://sonnet.io / 11ty where I have more control over the UX.
Thank you! I'm with you on getting things out sooner rather than later, and this certainly wouldn't have been something to hold up shipping something over; just wanted to report it in the hopes of a future fix.
The ability to interact with the renders is lovely, but the point stands that it's interfering with normal page scrolling.
Normal browser scrolling logic has a mechanism to avoid such conflicts; if you have some sub-element that's scrollable, a continuous scroll motion that started over the page body will continue scrolling the page body, even if a scrollable sub-element passes under the cursor. If you move the mouse over a sub-element and then try to scroll, then it'll scroll the sub-element.
Whatever this page is doing is breaking that logic.
Whatever this page is doing is breaking that logic.
They told you what it's doing. There is a webgl window that your cursor is hitting and the input is going to that. It should be pretty clear, you can see the 3D window view start changing.
Yes and the right thing to do given additional time to improve UX is that webgl windows should require focus before capturing the scroll events.
Click on the embed, focus border appears, now scrolling with the mouse within the window scales the rendering. Scrolling outside or clicking away from the embed returns the scrolling behavior to normal. This is one of those things that breaks the simple model of "lazy composability."
The person you replied to, me, understood perfectly why the window stopped scrolling, and considers it a bug. Browsers know how to handle that with native scrollable elements, and a scrollable element doesn't normally "capture" the scroll when it passes under the cursor. This element should ideally behave the same way.
"Whatever this page is doing" was with regards to the implementation details of the elements in question, not the actual reason why the issue was happening.
(I don't think "click before scrolling" is necessarily the right UI fix here, though. Ideally it'd be browser-style "if scrolling starts on the UI element it scrolls that element, but not if it just passes over that element during a scroll of the page".)
Please add RSS to your blog thing. It's not dead technology, there's still some people like me that would like to keep up-to-date with other people's writing, but I won't give out my email for any newsletter until you buy me lunch first.
Please add RSS. Thank you. This is a good blog, that now I am gonna forget forevermore.
(Can't comment on TFA because I have my iPhone set to Lockdown Mode and WebGL is disabled, so nothing shows up. It's on purpose.)
Hey, hey, I would love to do that know but I won't be able to before spring next year. That's when I'll merge untested back into my main site (sonnet.io)
the site uses obsidian publish so a lot of things about it are rudimentary. Obsidian is a nice note-taker but the publication platform bit is just a side thingy. also, you can't comment on TFA because it simply does not do comments.
SDFs are cool, but they have the problem that they become very slow very fast. If all you want are a few abstract shapes they're great. But, as soon as you want something more real world, they slow to a crawl.
It depends. High complexity with SDFs is possibly cheap. It just has to be procedural. For example a single 3D-cube has the same computational cost like an infinite array of 3D-cubes in SDFs.
Yeah their neatness is certainly not as a replacement candidate for the good old 100000s-of-on-screen-meshes via millions-of-on-screen-triangles 60+FPS real-time rendering. Instead cool as a primitive / toolbox item for all kinds of "authoring"-related side quests. Font rendering too. Or shadertoy.com ray marchers, or goopy 3D design as GP linked to (to then export as meshes, naturally).
