You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When all fallback positions fail, the current spec tells to use the last fallback position.:
If the previous step finished without selecting a set of styles, use the adjusted styles corresponding to the final entry in the position fallback list.
This creates a strange behavior where a rather big element will be placed at a position where it is hardly visible on the screen, whereas other positions provided better visibility.
In this demo the anchor (pink) is close to the bottom of the page, so the anchored element (cyan) is hardly visible. If it was positioned on top, it would be mostly visible.
I propose changing the spec to select the fallback position which provided more element area to be visible on screen.
As next actions, the author may choose to limit the size of the anchored element to fit the screen.
Think dropdown with many items. It must be positioned under the trigger or above if there is more space above. Then dropdown's height may be limited to fit on the screen and cause scroll inside the dropdown menu.
The text was updated successfully, but these errors were encountered:
From an implementation point of view this breaks an important optimization that we are able to take compared to selecting the last try.
Specifically determining the width (inline-size) of an element is relatively cheap, compared to determining the height (block-size). Today we determine the width, then can check if it fits then skip to the next try-block without performing a full-layout. With selecting the "most visible" we'd need to perform a full layout on each try-block if nothing completely fitted.
If instead of checking for the largest anchor element size, you simply checked for which yielded the largest inset-modified-containing block, you could perform the sort pretty easily I should think.
We've provisionally added position-try-order to handle this. Rather than being based on the element's size itself, it just checks the size (in some axis) of the inset-modified containing block that results from each option's styles. See proposal
When all fallback positions fail, the current spec tells to use the last fallback position.:
This creates a strange behavior where a rather big element will be placed at a position where it is hardly visible on the screen, whereas other positions provided better visibility.
In this demo the anchor (pink) is close to the bottom of the page, so the anchored element (cyan) is hardly visible. If it was positioned on top, it would be mostly visible.
I propose changing the spec to select the fallback position which provided more element area to be visible on screen.
As next actions, the author may choose to limit the size of the anchored element to fit the screen.
Think dropdown with many items. It must be positioned under the trigger or above if there is more space above. Then dropdown's height may be limited to fit on the screen and cause scroll inside the dropdown menu.
The text was updated successfully, but these errors were encountered: