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.
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".)
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.
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.
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).
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.
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.)
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.
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)
30 comments
[ 5.3 ms ] story [ 70.9 ms ] threadNormal 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.
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.
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."
"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.
The author of the page considered it a bug as well: https://news.ycombinator.com/item?id=38598921
(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".)
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.
* https://untested.sonnet.io/111
Thanks for a really interesting post!
They come up from time to time. For example, Womp3D[0] uses them.
[0] https://womp.com/
Basically, signed distance fields allow high resolution renders from low resolution rasters which represent character shape.
It's used by many web font rendering libraries esp for maps
Presumably it's bucketing the interactions somehow to remain fluid.
Quick intro to Janusz:
https://untested.sonnet.io/How+to+draw+a+Janusz
How to become Janusz:
https://untested.sonnet.io/The+Janusz+I+Live+In
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.)
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.
https://untested.sonnet.io/Abusing+and+reviewing+Obsidian+Pu...
https://sonnet.io/feed.xml ← feel free to subscribe here and see you then!
> until you buy me lunch first.
I completely get the point and use anonymised emails for my newsletter subs. I won't buy you lunch, but here's a chilli recipe that might help:
https://untested.sonnet.io/Chilli+for+Your+Mom