Closed Bug 1924792 Opened 1 year ago Closed 6 days ago

Implement position-area "shifting" for containing block overflow

Categories

(Core :: Layout, enhancement, P3)

enhancement
Points:
1

Tracking

()

RESOLVED FIXED
148 Branch
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.

Whiteboard: [anchorpositioning:m1]
Whiteboard: [anchorpositioning:m1] → [anchorpositioning:pickup]
Whiteboard: [anchorpositioning:pickup] → [anchorpositioning:m1][anchorpositioning:pickup]

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.

Whiteboard: [anchorpositioning:m1][anchorpositioning:pickup] → [anchorpositioning:reserve]
Whiteboard: [anchorpositioning:reserve] → [anchorpositioning:backlog]
Summary: Implement anchor positioned element "shifting" for containing block overflow → Implement position-area "shifting" for containing block overflow

Not really part of the initial support, which has landed. Changing this to block the main meta bug.

Blocks: css-anchor-position-1
No longer blocks: 1909336
Whiteboard: [anchorpositioning:backlog] → [anchorpositioning:m3]
Blocks: 2003568
Depends on: 2003519, 2003528, 2003548
No longer depends on: 2003519, 2003528, 2003548
Duplicate of this bug: 2003591
Assignee: nobody → dshin

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.

User Story: (updated)
Status: NEW → ASSIGNED
Depends on: 2004495

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 of position-area.
No longer blocks: 2003519, 2003528, 2003548
No longer duplicate of this bug: 2003591
Whiteboard: [anchorpositioning:m3] → [anchorpositioning:m3][anchorpositioning:continuation]
Whiteboard: [anchorpositioning:m3][anchorpositioning:continuation] → [anchorpositioning:continuation]
Points: --- → 1
Blocks: 1897279
Attachment #9535145 - Attachment description: Bug 1924792 - If an anchored element overflows its position-area IMCB, try to shift it to stay within the original CB.. r=#anchor-pos → Bug 1924792 - If an anchored element overflows its position-area IMCB, try to shift it to stay within the original containing block. r=#anchor-pos
Pushed by jkew@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/2a64929749ca https://hg.mozilla.org/integration/autoland/rev/cdeb248c5061 If an anchored element overflows its position-area IMCB, try to shift it to stay within the original containing block. r=layout-anchor-positioning-reviewers,layout-reviewers,emilio
Status: ASSIGNED → RESOLVED
Closed: 6 days ago
Resolution: --- → FIXED
Target Milestone: --- → 148 Branch

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.

Assignee: dshin → jfkthame

:jfkthame, could you consider nominating this for a release note? (Process info)

Flags: needinfo?(jfkthame)

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.)

Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: