1924231 - Evaluate visibility of anchor element (position-visibility: anchors-visible)

Status: RESOLVED FIXED

(Core :: Layout: Positioned, enhancement)

Description

[David Shin[:dshin]]

position-visibility: anchors-visible requires this.
May amount to something similar to content-visibility: auto, but focus is not taken into account, just if the anchor element is clipped out.

Comment 1

[David Shin[:dshin]]

Follows a specific definition of the anchor being visible: "If the box has a default anchor box but that anchor box is clipped by intervening boxes, this box is also strongly hidden."

Where "clipped by intervening boxes" is "An anchor box anchor is clipped by intervening boxes relative to a positioned box abspos relying on it if anchor’s ink overflow rectangle is fully clipped by a box which is an ancestor of anchor but a descendant of abspos’s containing block." So we need an additional check here beyond getting the right anchor.

Should also be noted that it only cares about the default anchor box - It doesn't matter if it ends up being used (e.g. position-anchor: --foo; left: anchor(--bar, right) only cares about the visibility of --foo, not --bar).

Comment 2

[David Shin[:dshin]]

This work will be done at ResizeObserver event time, within the framework provided by Bug 1962471

Comment 3

[Emilio Cobos Álvarez [:emilio]]

So my read of the whole position-visibility thing is that it's supposed to happen during layout of the anchored box, not at ResizeObserver time. I'm not convinced that's a great idea for position-visibility: anchors-visible, but I filed https://github.com/web-platform-tests/interop/issues/998 / https://github.com/w3c/csswg-drafts/issues/12732 about it.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

From conversations with David, I think the idea this bug was to start using the ResizeObserver timing for position-visibility, but reading some of the context of position-visibility, it seems the intention is for it to be done during layout (that's why anchors-visible only checks overflow of the intermediate containing blocks, rather than something more interesting like IntersectionObserver).

That said, the whole state of that seems rather sad. There's not a single test for force-hidden whatsoever, and I'm not convinced the proposed behavior is great: https://github.com/w3c/csswg-drafts/issues/12732 / https://github.com/web-platform-tests/interop/issues/998

I tend to agree that this should ideally use that timing to be a bit more sophisticated, but I don't think we want to go ahead with that without getting the spec sorted out first.

Comment 5

[Jonathan Watt [:jwatt]]

Yeah, that seems right. Thanks for digging into this to get us more clarity.

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

As you know (but just to transfer the information here), it seems that Chrome uses their intersection observer code for this, but runs it in the resize observer loop just prior to the resize observers.

https://github.com/w3c/csswg-drafts/issues/12732#issuecomment-3255974085

In the following comment on the github issue you seem positive about that approach. This bug seems very important to being able to ship so, given that, would you be willing to work on this while the spec work is in progress (under the assumption if Chrome and we both align on the same behavior we can get that spec'ed)?

Comment 7

[Emilio Cobos Álvarez [:emilio]]

This bug seems very important to being able to ship

Is it? I was assuming shipping without anchors-visible support wouldn't be a huge deal? It was a relatively late addition to the spec.

would you be willing to work on this while the spec work is in progress (under the assumption if Chrome and we both align on the same behavior we can get that spec'ed)?

Well WebKit seems to thing the current spec (which uses a totally different approach) is fine, so I'd personally rather wait before implementing one thing and then switching to another. It doesn't seem particularly terrible to implement either way tho, it's just very different...

Comment 8

[David Shin[:dshin]]

To clarify - this ticket specifically concerns position-visibility: anchors-visible, where we:

1. Evaluate anchors that are no longer visible (i.e. "clipped by intervening boxes")
2. Map affected anchors to relevant positioned elements (i.e. Has affected anchor as default anchor) that have position-visibility: anchors-visible
3. Update affected positioned frames' visibility flag (Bug 1962471)

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1924231 - Implement of position-visibility: anchors-visible. r=#anchor-pos

There's one scrolling issue I need to sort out, but this is good enough
for an initial pass.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fbcdc966d0c3
https://hg.mozilla.org/integration/autoland/rev/862548b90dc0
Implement of position-visibility: anchors-visible. r=layout-anchor-positioning-reviewers,firefox-style-system-reviewers,layout-reviewers,dshin

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5f28dfcc14b5
https://hg.mozilla.org/integration/autoland/rev/c91d6e83f153
Update property-database for anchors-visible.

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56411 for changes under testing/web-platform/tests

Comment 14

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/862548b90dc0
https://hg.mozilla.org/mozilla-central/rev/c91d6e83f153