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
According to the specification, the anchor element is "clipping", if anchor’s ink overflow rectangle is fully clipped by an element which is an ancestor of anchor but a descendant of abspos’s containing block.
If the anchor element is in the top layer (such as a Popover), then the block containing it is the viewport.
As a result, the anchor element is in the top layer overflowed the container when the position-visibility: no-overflow property is set.
When the anchor element is a simple <div></div> element (can be seen by removing the popover="auto" attribute), the element is clipped correctly
Given the functionality currently in the spec, no. As you say, the no-overflow value depends on it overflowing its CB, and when it's in the top layer that's very high. (Not necessarily the viewport; if it's an abspos top layer it's just using the ICB.)
The plan is that we'll have a new positioning property, provisionally called position-container, which points to some arbitrary element and causes the abpos to generate its CB from that element (plus clip the same as that element, etc, so it looks like it's contained by the scrollers, etc.) See #9868
According to the specification, the anchor element is "clipping", if anchor’s ink overflow rectangle is fully clipped by an element which is an ancestor of anchor but a descendant of abspos’s containing block.
If the anchor element is in the top layer (such as a Popover), then the block containing it is the
viewport
.As a result, the anchor element is in the top layer overflowed the container when the
position-visibility: no-overflow
property is set.When the anchor element is a simple
<div></div>
element (can be seen by removing thepopover="auto"
attribute), the element is clipped correctlyExample of this case: https://codepen.io/pont1s/pen/zYQdPoo (Chrome >= 125)
I think this is a common use case, is there any way to implement the expected behavior?
The text was updated successfully, but these errors were encountered: