I understand that this release is marked alpha, nonetheless it's pretty funny that opening the dropdown in the first example snippet on the page disables scrolling for the whole page. While it isn't trivial, custom dropdowns that work regardless of container overflow are a solved problem, just pick one of the common solutions and use it.
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...
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.
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.
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?
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.
For more information on the actual issue this comment mentions:
The page applies `overflow: hidden` to the root element, which isn’t a very good solution to the “you shouldn’t be able to scroll the document while a dropdown is open” problem. It tries to counteract the scrollbar shift problem this causes by applying corresponding padding to the root element (which is still yuck, because the scrollbar still visually disappears, which it shouldn’t), but the page uses `position: fixed` for the header and right ToC sidebar, which bypasses the document padding. End result, opening a dropdown shifts parts of the document, which is bad.
I’m not sure if there’s a proper solution that makes it behave how a <select> does on desktop platforms; historically there wasn’t, and every historical workaround causes worse problems than it solves, in my opinion. Also in my opinion, the problem was never particularly important; the only part that was even vaguely notable was scroll chaining, and you can now just specify `overscroll-behavior: contain` on the dropdown popup to categorically fix that. (Browser support: 7½ months in Safari, 5–6 years elsewhere.) Very recently, browsers have been getting better support for modal concepts, driven by the <dialog> element and the corresponding concept of a top layer, as the spec calls it. I haven’t played with it, but I suspect that this might finally be the actual solution to the problem of stopping scrolling underneath.
The most common solution used today is Popper, which essentially takes the relevant element out of the DOM and makes it a fixed element with transforms on body (or any element of your choice) instead. It's used by many large projects such as react-select etc. This is an approach that wouldn't have worked well in the days of old due to delays in updating the UI, but modern browsers are very capable with it and there are no discernible issues with alignment. I agree however that native elements are way better wherever that's a valid option since they also have corresponding native elements on mobile devices etc.
React Aria puts its popups in such a separate place in the DOM like you’re saying.
But the part I and the parent were remarking upon is what you do about scrolling.
Popper’s (default) answer is “recalculate the preferred position [and size, I think?] on every scroll event”. This is perfectly fine, and sometimes preferable.
React Aria’s answer is “position once and then prevent scrolling”. This matches all platforms’ conventions for these sorts of elements, it’s just that the way they’ve implemented it has problems, problems that may be unavoidable at present.
Is it possible the doc page is just not laid out well and that's causing weird interactions with how the component tries to stop scrolling? I imagine it also tries to stop in the nearest scroll port, which just happens to be the root here.
In any case I'm sure they will fix it if you open an issue against it..
Isn't the proper solution to just use the HTML <select> element, instead of one that recreates the visual, recreates the behavior with JavaScript, and recreates the semantics with ARIA?
<select> is terribly limiting. Options can be a single line of plain text, with some platforms letting you control colour and font, and you get only very basic selection by typing, on desktop platforms only in general.
The “Favorite Animal” dropdown shown in the linked page can be done with <select> with no loss, and therefore I’d say probably should be. But you can often do much better by skipping past <select>:
Also it doesn't appear to work at all on android Firefox - tapping the dropdown just shows all entries and then they disappear before you can select one!
