4 ms·

They're not images, you're interacting with them. You can zoom, but also move/rotate the rendered items as well.

JoshTriplett 3y ago
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.
- 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 ago
    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."
    - CyberDildonics 3y ago
      That 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 ago
        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. 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".)

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.

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 ago
  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."
  - CyberDildonics 3y ago
    That 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 ago
      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. 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".)