Baseline status for Anchor positioning

[jamesnw]

Anchor positioning is currently marked as supported in Chrome and Safari, with Firefox currently behind a flag, and potentially releasing it without a flag in December. At that point, if we do nothing, Anchor Positioning as a complete unit will progress to Baseline Newly available.

At this point, I don't think that's the right move, and I think we should consider this in advance of Firefox releasing the feature.

Roma Komarov called this out in a recent blog post-

While it might seem that anchor positioning is already present in some stable versions of browsers, in reality it is further from being even baseline. If, today, Firefox would release anchor positioning into its stable version, even if Firefox itself will be perfect, there are enough issues, starting from feature’s usability (absent features like being able to change the containing block) to bugs in stable versions of browsers that prevent many use cases from being viable.

Jake Archibald also saw this as an issue here- #3382 (comment)

Some of the issues I'm aware of-

• Anchored Fixed position elements is broken in Safari
• Lots of position-try edge cases and bugs
• New keywords for position-area that haven't shipped anywhere yet (but would not warrant their own feature)
• In Chromium, a positioned element that overflows its containing block is placed incorrectly.
• Popover placement is a major stumbling block, and while there have been multiple attempts to address this, the latest resolution has not yet been added to the spec.

Note that most of these are behavioral, and may not be captured by BCD directly. I don't think breaking it into smaller subfeatures will help in this situation.

The feature is currently computing its status from anchor-name, position-anchor and anchor().

Looking ahead, there are some concrete subsets that would make reasonable features within an Anchor Position group, such as Anchor positioning elements with transforms, Container queries for detecting fallback, and anchor attribute.

In its current state, I would consider anchor positioning to be in beta. While a happy path is possible, I'm not confident that there won't be additional breaking changes, and it comes with significant caveats and unknowns. We don't have a "Baseline Beta" status (🤔)- what other options do we have to reflect this?

[captainbrosset]

Discussed at the WebDX CG today:

• Confirmed from the Interop 25 side of things.
• We should be conservative rather than optimistic here.
• We could remove the compute_from statement to keep this from reaching Baseline.
• What, in BCD, do we need to add or fix? The partial implementation flag could be used.
• Anchor positioning has evolved a lot over time. There's a simple happy path scenario that works well in 2 engines, and soon in 3, it'd be nice to make sure the scope of our current features matches that scenario, and then split out the other keys into other features.

[ddbeck]

Thanks for filing this, @jamesnw.

I opened #3574 to remove the compute_from, which would buy us time to make a finer distinction around anchor positioning (or more than one anchor positioning feature, if desired). We could leave that PR open until the last minute, even, to consider other approaches first.

I also have a follow up question for @jamesnw. Can you help me figure out which compat keys would (or don't represent) the open issues you're aware of? It'd be nice to see if we can't represent some of this in BCD.

Some of the issues I'm aware of-

• Anchored Fixed position elements is broken in Safari

css.properties.position.fixed + some AP property?

• Lots of position-try edge cases and bugs

css.properties.position-try.*? Any bug URLs, for a taste?

• New keywords for position-area that haven't shipped anywhere yet (but would not warrant their own feature)

Do you have examples of this? Are they not listed at all in this compat table? Or do you mean the ones that are just not shipping stable yet?

• In Chromium, a positioned element that overflows its containing block is placed incorrectly.

In that same compat table, are these the issues noted for top and so on? Or are these new bugs not shown in the compat table?

• Popover placement is a major stumbling block, and while there have been multiple attempts to address this, the latest resolution has not yet been added to the spec.

Is there a spec change PR or discussion that we could link to? (I think in the WebDX call you suggested that this might be a breaking change, which might merit adding the BCD early, given the risk of confusion possible for this feature overall.)

[jamesnw]

• Anchored Fixed position elements is broken in Safari

css.properties.position.fixed + some AP property?

Hmm. An element that has position: fixed AND uses position-area: * or inset: anchor() (or anchor-size(), likely, but I haven't tested it) AND has a default position anchor that scrolls is very glitchy. I'm not sure how to cover that in a BCD key, and I suspect this is just one way that a larger bug with scrolling presents.

• Lots of position-try edge cases and bugs

css.properties.position-try.*? Any bug URLs, for a taste?

https://bugs.webkit.org/show_bug.cgi?id=302008 (position-try + nested popover crashes)
https://bugs.webkit.org/show_bug.cgi?id=302712 (position-try + anchor(inside) bug)
https://issues.chromium.org/issues/461560381 (same as above, in Chromium)
https://issues.chromium.org/issues/425894800 (position-try + scroll issues)

• New keywords for position-area that haven't shipped anywhere yet (but would not warrant their own feature)

Do you have examples of this? Are they not listed at all in this compat table? Or do you mean the ones that are just not shipping stable yet?

An example would be self-x-start. It looks like the BCD data already has switched to the new format, and shows the old (x-self-start) as an alternate name. AFAICT, the new format won't ship anywhere until next month.

• In Chromium, a positioned element that overflows its containing block is placed incorrectly.

In that same compat table, are these the issues noted for top and so on? Or are these new bugs not shown in the compat table?

I think this is the same bug, but broader than noted in the compat table. https://issues.chromium.org/issues/438334710

• Popover placement is a major stumbling block, and while there have been multiple attempts to address this, the latest resolution has not yet been added to the spec.

Is there a spec change PR or discussion that we could link to? (I think in the WebDX call you suggested that this might be a breaking change, which might merit adding the BCD early, given the risk of confusion possible for this feature overall.)

The resolution is here w3c/csswg-drafts#13067 (comment), but the issue is here - w3c/csswg-drafts#10258.

Also, there's this position-area bug in Chrome- https://issues.chromium.org/issues/388575663, which causes position-area to position non-anchored elements.

A lot of these seem to point to interaction between keys, which I imagine is difficult to capture well in BCD.

[ddbeck]

Thank you, @jamesnw. That's very helpful!

I also found this issue on BCD, which seems to reflect a spec change, positioning with respect to transforms, mentioned in passing here that I did not understand as breaking: mdn/browser-compat-data#28499.

To me, the top compat issues to expose to developers in BCD would probably be:

1. Breaking spec changes. As far as I can tell, there are two: anchor positioning after transforms and position-anchor: none. I think both have shipped in Chrome, so we could add them to BCD.

   For position-anchor, a case might be made to mark css.properties.position-anchor as partial for those that don't have none as the initial value (assuming Mozilla and WebKit are positive toward it). Naturally, we'd add the css.properties.position-anchor.none key too (and pin our anchor positioning feature to it).

   For transform behavior, we could add a key to show that behavior, but it seems like an awfully suspect candidate for a behavioral subfeature, when it's not additive or feature detectable. Assuming Mozilla and WebKit are positive toward it (uncertain, see CSS anchor positioning with transforms WebKit/standards-positions#558 and CSS anchor positioning with transforms mozilla/standards-positions#1302), we could mark one or more keys as partial when this is not implemented. I'm not sure what the most relevant key(s) would be though. Maybe css.properties.anchor-name, since it's something to do with the bounding box of the anchor element? (I really ought to make something with this feature so I can get my head around it better.)

2. Crashing bugs. It looks like https://bugs.webkit.org/show_bug.cgi?id=302008 is the only one right now, but that looks easy enough to stumble into to qualify for a partial in BCD.

The other glitchy stuff is hard to describe and hard to characterize as compat issues (especially cases like that bug that appears in both WebKit and Chromium). I think for those, we add them as notes in BCD (where they can be made to make sense), but not as partials. We can promote those bugs to partial-causing, if more developers gripe about them specifically.

[jamesnw]

position-anchor and popover

It does look like position-anchor defaults to none in Chrome Canary, and it makes sense to add that to BCD. However, I confused some issues, and that doesn't actually relate to popovers. 🤦

For popovers, the relevant resolution is "auto margins are disabled if position-area is not none". This most directly impacts popovers, which have a UA style of margin: auto. This is in Chromium and Safari (at least in the pre releases, but not releases), but not Firefox. Perhaps this would be a behavioral subfeature on position-area for disables_margin_auto, or partial implementation in Firefox of position-area. I do think this blocks the larger feature from being baseline.

Transforms and anchor positioning

I don't think this is breaking, but rather a new ability (avoiding the word feature here) of transformed elements. If this could be reflected in BCD keys, perhaps as a behavioral subfeature of transforms, then I think this could be a feature separate from Anchor Positioning (to be grouped later). It is additive, but not feature detectable (I don't think).

Overall, I think the 1st issue is a blocker for baseline, and the second a good candidate for a subfeature. Ideally, Firefox will ship both simultaneously, and then it wouldn't need to be a separate feature.

[ddbeck]

We discussed this on the WebDX call today. A couple notes:

• I promised a follow up here to enumerate the changes we (meaning I) should submit upstream to BCD. I'm planning to do that tomorrow.
• We're expecting Firefox to ship anchor positioning next week. As a short-term fix, I'm going to merge Remove compute_from from anchor positioning #3574 to prevent the status from advancing. I'll do that now.

[rviscomi]

@ddbeck should we also add a regression note to the pending PR #3187?

cc @bramus and @una who had thoughts on Baseline blockers for this feature

[ddbeck]

@ddbeck should we also add a regression note to the pending PR #3187?

@rviscomi No, I don't think so. It's not a regression, at least not as we've used the term to date. The feature never reached a Baseline status, so the status never went backwards (or forwards).

In a stricter sense, the list of supporting browsers shrank, but I think it would add a lot of noise (and a lot of work—unless we sought to automate it) to note changes in the set of supporting browsers before a feature reaches Baseline. Especially at the time when a feature first ships in a browser, there's often churn (e.g., data is off by one release due to confusion or test ambiguity; features getting delayed very late in betas; newly discovered bugs).

[ddbeck]

OK, finally getting to what we ought to do upstream in BCD, though not necessarily all at once:

• Add key css.properties.position-anchor.none
  • https://issues.chromium.org/issues/460415950
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1999972
• Set css.properties.position-anchor to partial_implementation where "make [none] the initial value" is not implemented
  • Include https://issues.chromium.org/issues/460415950 in note
  • Find bug URL for Gecko and include in note
  • Find bug URL for WebKit and include in note
• Set css.properties.position-area to partial_implementation where "auto margins are disabled if position-area is not none" is not implemented.
  • Find bug URL for Chromium and include in note
  • Find bug URL for Gecko and include in note
  • Find bug URL for WebKit and include in note
• Add key css.properties.anchor-name.position_after_transform
  • Find bug URL for Chromium and use as impl_url
  • Find bug URL for Gecko and use as impl_url
  • Find bug URL for WebKit and use as impl_url
• Add a note to css.properties.position-area regarding https://issues.chromium.org/issues/388575663
  • Promote this to partial_implementation, if it satisfies the BCD guideline (need to review this to be sure)

Some other things ought to happen or have happened (I think it's mostly the new values that #3558 (comment)), but BCD already has a good process to capture that so I'm not going to worry about it for now.

I'm going on holiday shortly, so if anyone wants to start on any or all of this before 2026, feel free. You can even request me as a reviewer on BCD and I'll take a look when I get back. Thank you!