Why is the Positioner element considered an outside click?

[Jonas-C]

Hi! Scrollable components like selects and comboboxes could benefit greatly from counting clicks within the Positioner element as an inside click. This could allow for new compositions where the scrollable portion ( the Content) can be scrolled with both the keyboard and the mouse while still allowing for some content within the positioner to be non-scrollable. There's a couple of components in the ark examples that could need this composition. Notice how the focus disappears when you use the keyboard to scroll this, for instance. Now imagine that you'd like to display some pagination beneath the scrollable list. An alternative solution to this would be to scroll within the nearest parent when using the keyboard, but I think this would be more difficult to implement.

As it stands, you'll have to check if a click happens inside of the positioner, or live with the fact that everything within the Select/Combobox is scrollable. It seems like most components with a Positioner element already matches or overlaps the Positioner element, so this seems like a low-risk play. If one were to do this, you'd also have to hide the positioner as well as the content when the Select/Combobox is not open. What do you think?

[segunadebayo]

I’d say for consistency reasons, we wouldn’t want to do that but you raise a valid point.

The positioner should only be used for positioning or placing the content. Hiding the positioning esp when animation getting involved gets messy. We tried this in Ark, syncing the timings and animation states can be challenging.

The positioner for popover, select, etc. should work similar to those of dialogs else we’ll be creating an inconsistent mental model.

I’d recommend doing most of the work within the content to be honest. Might require a new element or so, but it keeps the structure consistent and predictable.