The current implementation of boundary detection is not ideal.
We recently added support for position:absolute when used in the document (https://github.com/Jemt/Fit.UI/commit/95f30aa3c2f0a8d741e959d707991434d3fc089c), but it uses position:fixed when placed in a container with overflow (overflow:auto|scroll|hidden) since this allows it to escape its boundaries. While that is smart, it also results in the pulldown menu being "detached" from the control, allowing the user to scroll away from the actual control from the pulldown menu - it sticks to the screen. Furthermore (and possibly worse) it results in incorrect positioning within a container that uses the CSS properties animation and transform since these creates a new stacking context which results in position:fixed becoming relative to the container rather than the viewport.
We should change the implementation so that a container with overflow becomes the "viewport" instead, against which collisions are detected, and have it use position:absolute in this case. This has the downside that the control will no longer be able to escape its boundaries, and it will not work well for small containers (50-100px high) - but we could add a flag allowing us to set the boundary detection to use the real viewport and position:fixed instead if such use cases are needed.
Something like:
DropDown.DetectBoundaries([enabled:bool[, relativeToViewport:bool]])
The relativeToViewport argument should default to false.
Most often when a control is hosted in a container with overflow, this container acts as the scrollable document - a classic layout with a navigation area, header, footer, and the main area for content which has overflow:auto. In such cases the suggested implementation would work much better.
A scrollable container placed in a scrollable document may not work well. The scrollable container can be partially scrolled out of view. So unless boundary detection is enabled with the relativeToViewport flag set to true, the DropDown will use the container with overflow, and possibly open outside of the real viewport. But that is exactly what relativeToViewport is there to solve.
The current implementation of boundary detection is not ideal. We recently added support for position:absolute when used in the document (https://github.com/Jemt/Fit.UI/commit/95f30aa3c2f0a8d741e959d707991434d3fc089c), but it uses position:fixed when placed in a container with overflow (overflow:auto|scroll|hidden) since this allows it to escape its boundaries. While that is smart, it also results in the pulldown menu being "detached" from the control, allowing the user to scroll away from the actual control from the pulldown menu - it sticks to the screen. Furthermore (and possibly worse) it results in incorrect positioning within a container that uses the CSS properties animation and transform since these creates a new stacking context which results in position:fixed becoming relative to the container rather than the viewport.
We should change the implementation so that a container with overflow becomes the "viewport" instead, against which collisions are detected, and have it use position:absolute in this case. This has the downside that the control will no longer be able to escape its boundaries, and it will not work well for small containers (50-100px high) - but we could add a flag allowing us to set the boundary detection to use the real viewport and position:fixed instead if such use cases are needed.
Something like:
DropDown.DetectBoundaries([enabled:bool[, relativeToViewport:bool]])The relativeToViewport argument should default to false.Most often when a control is hosted in a container with overflow, this container acts as the scrollable document - a classic layout with a navigation area, header, footer, and the main area for content which has overflow:auto. In such cases the suggested implementation would work much better.
A scrollable container placed in a scrollable document may not work well. The scrollable container can be partially scrolled out of view. So unless boundary detection is enabled with the relativeToViewport flag set to true, the DropDown will use the container with overflow, and possibly open outside of the real viewport. But that is exactly what relativeToViewport is there to solve.