3 ms·

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 scroll

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.

chrismorgan 4y ago
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.
- Etheryte 4y ago
  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.
  - chrismorgan 4y ago
    I think you might have misunderstood the situation. Popper supports putting popper elements somewhere else in the DOM, but that’s not their general recommendation (https://popper.js.org/docs/v2/performance/#attaching-elements-to-the-dom https://popper.js.org/docs/v2/performance/#attaching-element...). 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.
    - Rapzid 4y ago
      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..
- remram 4y ago
  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?
  - chrismorgan 4y ago
    <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>: • Use more than just plain text in each option (very simple example: https://react-spectrum.adobe.com/react-aria/Select.html#complex-items https://react-spectrum.adobe.com/react-aria/Select.html#comp...; also think of things like adding icons) • Support typing on all platforms (and no, native combo boxes à la <input list="…"> + <datalist> aren’t far off completely useless in practice). • Support typing with more complex matching, e.g. in a country selector supporting US/USA/United States, NL/Netherlands/The Netherlands/Holland, &c.
    - tadfisher 4y ago
      Funny enough, all of those examples are broken on Firefox for Android; they show on tap, then immediately hide.
devongovett 4y ago
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#discussioncomment-4275948 https://github.com/adobe/react-spectrum/discussions/3802#dis...
- ricardobeat 4y ago
  Nice work! Interaction design has been often reduced to a shouting match, and it’s great to see a more considered approach being taken.
- remram 4y ago
  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?
  - paulddraper 4y ago
    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.
    - happytoexplain 4y ago
      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?
      - 4y ago
worble 4y ago
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!

chrismorgan 4y ago

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.

Etheryte 4y ago
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.
- chrismorgan 4y ago
  I think you might have misunderstood the situation. Popper supports putting popper elements somewhere else in the DOM, but that’s not their general recommendation (https://popper.js.org/docs/v2/performance/#attaching-elements-to-the-dom https://popper.js.org/docs/v2/performance/#attaching-element...). 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.
  - Rapzid 4y ago
    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..
remram 4y ago
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?
- chrismorgan 4y ago
  <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>: • Use more than just plain text in each option (very simple example: https://react-spectrum.adobe.com/react-aria/Select.html#complex-items https://react-spectrum.adobe.com/react-aria/Select.html#comp...; also think of things like adding icons) • Support typing on all platforms (and no, native combo boxes à la <input list="…"> + <datalist> aren’t far off completely useless in practice). • Support typing with more complex matching, e.g. in a country selector supporting US/USA/United States, NL/Netherlands/The Netherlands/Holland, &c.
  - tadfisher 4y ago
    Funny enough, all of those examples are broken on Firefox for Android; they show on tap, then immediately hide.

devongovett 4y ago

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#discussioncomment-4275948 https://github.com/adobe/react-spectrum/discussions/3802#dis...

ricardobeat 4y ago
Nice work! Interaction design has been often reduced to a shouting match, and it’s great to see a more considered approach being taken.
remram 4y ago
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?
- paulddraper 4y ago
  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.
  - happytoexplain 4y ago
    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?
    - 4y ago

worble 4y ago

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!