2027955 - implicit anchor positioning with pseudo element fail after scrolling

Status: RESOLVED INVALID

(Core :: Layout: Positioned, defect, P3)

Description

[mic.gallego]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

Steps to reproduce:

Hello,

I have been unable to re-create a minimal test case, so it might be a set of conditions on my website.

To reproduce the issue:

1. Open this store: https://stretch-theme-sand.myshopify.com/
2. Hover the link "learn" in the header to open the mega-menu, and see the overlay shadow.
3. While keeping your cursor on the link, scroll down the page. At some point, the overlay will disappear.

Actual results:

The overlay is positioned in a ::after pseudo element using this code:

.mega-menu:after {
inset-block: anchor(end) auto;
}

After scrolling for a bit, the overlay disappears on Firefox.

Expected results:

It therefore should follow the scroll and be visible all the time (this is what happens on Chrome and Safari).

Comment 1

[Emilio Cobos Álvarez [:emilio]]

I think it's a bug in the page? That rule looks like:

@supports (position-anchor: auto) {
  .mega-menu:after {
    inset-block: anchor(end) auto;
    height: 100%;
  }
}

However, they are missing position-anchor: auto itself? This seems to work as they expect:

@supports (position-anchor: auto) {
  .mega-menu:after {
    inset-block: anchor(end) auto;
    height: 100%;
    position-anchor: auto;
  }
}

David, can you sanity-check me? I think this is WAI... We should make sure that there's some test for this or something tho.

Comment 2

[mic.gallego]

Are you sure? The spec indicates that pseudo element automatically get the parent as the anchor, so as I understand the spec this should not be needed.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I think it's needed (either that or position-area rather than inset-block: anchor(end) auto, see the discussion in https://github.com/w3c/csswg-drafts/issues/13067.

The spec for position-anchor says that the initial value is normal: https://drafts.csswg.org/css-anchor-position-1/#valdef-position-anchor-normal

If position-area is none, behaves as none. Otherwise, behaves as auto.

Since position-area is none, it behaves as none.

Comment 4

[mic.gallego]

You're correct, using position-area: auto seems to fix it! I think we can close it (although maybe it should be checked why the behavior is inconsistent across browsers here).

Comment 5

[David Shin[:dshin]]

Attachment: Testcase

Yeah, that is the latest resolution as far as I'm aware. It is a pretty recent resolution, and we in fact don't have normal implemented as of right now, and position-anchor's default value is none.

position-anchor: auto works, and should be the solution for people using anchor() functions instead of position-area, but right now using position-area does not cause us to look for implicit anchors. This is the same on Chrome Canary.

Notably, Safari TP seems to have the default value as auto, which may explain the divergence.

Side note - if someone specified @position-try fallback for these implicit anchor + position-area utilizing positioned elements with position-area: none + anchor() functions they'd lose the implicit anchor, which... could be interesting?

Comment 6

[David Shin[:dshin]]

(Closing this one as INVALID since we are technically closer to spec-compliant here)