Skip to content

[css-anchor-position-1] Select the fallback position where more content is visible, not the last #9047

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tigrr opened this issue Jul 9, 2023 · 4 comments

Comments

@tigrr
Copy link

tigrr commented Jul 9, 2023

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.

@bfgeek
Copy link

bfgeek commented Jul 21, 2023

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.

@fantasai
Copy link
Collaborator

fantasai commented Feb 8, 2024

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.

@tabatkins
Copy link
Member

tabatkins commented Feb 8, 2024

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

@tabatkins
Copy link
Member

We resolved to accept this in #9196 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Tuesday morning
Development

No branches or pull requests

4 participants