Re: [csswg-drafts] [css-anchor-position-1] Better handle an inset-area edge case when the default anchor element is partially or completely outside the containing block (#9663)

So the issue was that, previously, inset-area was defined as something whose effects totally occurred at computed-value time, so we couldn't detect misordered lines and had to just let the chips fall where they may. Because we bias towards the startward insets (top left in English) when they're misordered, this happened to work reasonably when the anchor was off to the right or bottom of the CB (giving the results from your video), but did the wrong thing when it was above or to the left (we'd ignore the bottom/right, and only pay attention to the `top/left: 0`, so the positioned element would be trapped by the CB in those directions).

We just put up a new proposal for inset-area at <https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1836854109> which reverts that and makes inset-area a layout-time property, so we *can* detect misordered lines and have things work more naturally. We agree that the behavior should be the same regardless of what direction the anchor is outside of the CB, and it needs to be consistent with what happens as the anchor *approaches* the edge of the CB. We could either keep it stuck within the CB or keep it stuck to the anchor, and we think the most reasonable behavior is to make the "misordered" side be zero-size and stuck to the anchor. This is most consistent with the author's likely intent and the implicit intent of the default alignment, and what would happen if you used insets directly rather than inset-area.

That is, an `inset-area: top / all;` element, whose default anchor is way above the initial CB, will see an area-modified CB that's zero tall and flush with the top edge of the anchor. This is the same as if the author had written `top: auto; bottom: anchor(top);`.

(Note; %s in insets, margins, or width/height currently all resolve relative to the containing block size. With inset-area setting the containing block, they'd resolve relative to the inset-area-modified containing block, which is much more natural. It also tracks with the similar behavior of absposes whose CB is generated by a grid, where the grid positioning properties can adjust the containing block. If both occurred on one element, we'd nest the effects - grid first, then inset-area.)

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9663#issuecomment-1836875240 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 1 December 2023 22:41:31 UTC