2 ms·
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 t
by CyberDildonics 3y ago
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.
- Spivak 3y agoYes 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."
- CyberDildonics 3y agoThat might be your opinion on how things should work, but the person I replied to didn't understand why their window stopped scrolling.
- JoshTriplett 3y agoThe 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. The author of the page considered it a bug as well: https://news.ycombinator.com/item?id=38598921 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".)