Hacker News Reader

Comment by devongovett | Hacker News Reader

This was an intentional choice. Repositioning when an outer element scrolls is pretty janky in some cases because scroll events don’t fire at 60fps. Also it’s not possible at all in other cases, like if the trigger goes completely out of view. We used to close the popover in this case but this caused usability problems. The new behavior of preventing scroll actually matches native platforms like macOS and helps with these issues. I get that it’s a little opinionated but it was thoroughly considered, not just done out of laziness. More details in this answer: https://github.com/adobe/react-spectrum/discussions/3802#dis...

View on HN

I reckon it’s a mistake. Hiding scrollbars dynamically is unpleasant, and the degenerate cases like `position: fixed` seen on this particular page make it very unpleasant.

Embrace what the web exposes. Allowing document scrolling underneath is distinctly the lesser of two evils. With a bit of effort, you can block scrolling underneath in almost all cases, and I reckon that’s good enough and much better than what there is currently. (Also try asking browser makers, “y’know this ‘top layer’ thing you made for <dialog> modal presentation and fullscreen? Wouldn’t it be nice if we could prevent scrolling underneath a ::backdrop?”)

Facts. You have to forgo native scrolling and basically re-implement all desired scroll behavior in JS in order to get rid of fixed position scroll jank.

I've been interested in re-implementing smooth scrolling in JS to mimic native but.. Even if you hit solid native refresh at all time, I feel you'd have to switch your entire site to JS controlled scrolling for consistency and even then the scroll feel might not match native scroll on other pages per system settings.

It's a bit of a rabbit hole.

Never override scrolling in this way. Scrolljacking is always bad, because the web doesn’t expose the primitives required to make it anything else. You might be able to get it to match the platform you’re on exactly, but it will still be a trainwreck for many other users.

Okay

Nice work! Interaction design has been often reduced to a shouting match, and it’s great to see a more considered approach being taken.

Couldn't it be anchored to the page? Instead of anchored to the screen and require repositioning?

Is there a limitation in CSS preventing it?

The problem is the drop-down should never be cropped/hidden by the boundary of a parent container.

This runs counter to the behavior of it being anchored to a parent container.

Are you saying that you can only anchor an element to one of its ancestors? Can CSS really not define positional relationships between siblings (I'm used to Apple's Auto Layout)? If so, couldn't you add an additional outer container that doesn't crop its contents to its bounds and anchor the dropdown to that?

The problem is when your dropdown component (D) is in a scrolling container (2) in the page (1).

    -1-----------
    |           |
    |  -2---    |
    |  | D |    | 
    |  -----    |
    |           |
    -------------

If you attach the dropdown options to the inner container (2), they are cropped.

If you attach the dropdown options to the outer container (1), they don't scroll with the rest of their component (D).

----

Non-native dropdowns in general are handicapped.

For Windows/MacOS/Linux, native dropdowns can exceed the bounds of even the OS window. There is no CSS equivalent of this behavior.

If you have a trigger inside a nested scrollable region, and the popover pops out of this region, then if the trigger is scrolled out of view the popover cannot be anchored to it anymore.

Reply on news.ycombinator.com