Implement position-area "shifting" for containing block overflow
Categories
(Core :: Layout, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox148 | --- | fixed |
People
(Reporter: jwatt, Assigned: jfkthame)
References
(Blocks 3 open bugs)
Details
(Keywords: webcompat:platform-bug, Whiteboard: [anchorpositioning:continuation])
User Story
user-impact-score:200
Attachments
(1 file)
At the end of the position-area section there is a note about shifting when there's containing block overflow. We'll need to implement this behaviour.
Updated•1 year ago
|
| Reporter | ||
Updated•10 months ago
|
| Reporter | ||
Updated•10 months ago
|
Comment 1•4 months ago
|
||
Also see spec resolution added to "see also," that avoids layout inconsistencies when anchor is out of vs within the initial viewport.
However, I am unsure of what WPT implications, if any, as a result of this behaviour change.
Updated•3 months ago
|
| Reporter | ||
Updated•3 months ago
|
| Reporter | ||
Comment 2•3 months ago
|
||
Not really part of the initial support, which has landed. Changing this to block the main meta bug.
| Reporter | ||
Updated•2 months ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Comment 4•1 month ago
|
||
So we're position-area ends up using 0 for auto, but we're still changing alignment based on it:
However, if only one inset property in the relevant axis is auto, the default alignment is instead towards the edge with the non-auto inset; and this is an unsafe alignment.
This happened as part of this spec resolution.
Safari seems to implement this, but still agrees with Chrome on the usecase, except the manual additional inset without use of anchor functions. I believe the solution is that we should shift the offset by the position-area modified inset. e.g. With position-area: bottom right, left: anchor(right) should resolve to 0.
Updated•1 month ago
|
Updated•1 month ago
|
Comment 5•28 days ago
|
||
It seems that, after bug 1991929:
- bug 2003568 will mostly be fixed, though this bug is required to reach parity with Chrome
- bug 2003519, 2003528, 2003548 actually seem better served by bug 2003591, since they all specify
anchor()inset on top ofposition-area.
Updated•21 days ago
|
Updated•21 days ago
|
Updated•21 days ago
|
Updated•21 days ago
|
Updated•20 days ago
|
Updated•19 days ago
|
| Assignee | ||
Comment 6•7 days ago
|
||
Updated•7 days ago
|
Comment 8•6 days ago
|
||
| bugherder | ||
| Assignee | ||
Comment 9•5 days ago
|
||
Our rendering for the testcase in bug 2003568 now matches Chrome's; and this has fixed a couple of the WPT failures in bug 1897279.
Comment 10•4 days ago
|
||
:jfkthame, could you consider nominating this for a release note? (Process info)
| Assignee | ||
Comment 11•4 days ago
|
||
This doesn't really seem relnote-worthy to me; it's just an incremental fix/improvement to our anchor positioning support, which is a work in progress, but I don't think each fix we make in that feature gets its own individual note?
(But re-ping me if you think my understanding is off-base here.)
Description
•