Chrome 143 supports CSS Anchor Position Container Queries

[ddbeck]

Summary

This adds feature entries for container queries for anchor positioning.

Test results and supporting details

I tried a couple of demos on this to confirm that it's actually shipping, but https://chromestatus.com/feature/5177580990496768 is where I got the version number.

Related issues

via web-platform-dx/web-features#3403 and web-platform-dx/web-features#3564

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[caugner]

First pass, LGTM overall, but a few comments.

[caugner]

Why are we documenting this (behavioral?) subfeatures?

[ddbeck]

This is not a behavioral subfeature. It's a named container query "feature" (in media/container queries terminology, not the BCD sense), as in @container anchored(fallback: <some-value>).

Right now there's only one feature to query against, but it's possible other container query features could exist (e.g., @container anchored(foo-bar: <some-value>) would get a foo-bar key as a peer to fallback).

[caugner]

Can we add a suffix for clarity?

Suggested change

	"fallback": {
	"fallback_feature": {

[ddbeck]

I also modeled this feature after a scroll-state() descendant. If we do something different for anchor positioning, I think we ought to do the same for scroll-state.

[caugner]

Suggested change

	"anchor_position_queries": {
	"__compat": {
	"description": "Anchor position queries (`anchored()`)",
	"spec_url": "https://drafts.csswg.org/css-anchor-position-2/#anchored-container-queries",
	"anchored_function": {
	"__compat": {
	"description": "`anchored()` function",
	"spec_url": "https://drafts.csswg.org/css-anchor-position-2/#container-rule-anchored",

[ddbeck]

The spec change I agree with, but I'm reluctant to change the description and key name.

I modeled this feature after scroll-state() (see this compat table), where we describe the feature as "Scroll-state queries" and then nest the features for that query type under it. If we do something different for anchor positioning, I think we ought to do the same for scroll-state.

Also, I think "function" specifically is a risky term in this context. The spec text here is a bit loose (other specs use the phrase "functional notation" for at-rule syntax like this). I think it's mostly a convenience for the spec authors to call these functions. They kinda look like functions, but CSS "functions" as each is defined by its own grammar—there's no primitive function that specs reuse.

[caugner]

Can we add a suffix for clarity?

Suggested change

	"fallback": {
	"fallback_feature": {

[ddbeck]

Thanks for the review, @caugner! Accepted some of this, plus some commentary below.

[ddbeck]

The spec change I agree with, but I'm reluctant to change the description and key name.

I modeled this feature after scroll-state() (see this compat table), where we describe the feature as "Scroll-state queries" and then nest the features for that query type under it. If we do something different for anchor positioning, I think we ought to do the same for scroll-state.

Also, I think "function" specifically is a risky term in this context. The spec text here is a bit loose (other specs use the phrase "functional notation" for at-rule syntax like this). I think it's mostly a convenience for the spec authors to call these functions. They kinda look like functions, but CSS "functions" as each is defined by its own grammar—there's no primitive function that specs reuse.

[ddbeck]

I also modeled this feature after a scroll-state() descendant. If we do something different for anchor positioning, I think we ought to do the same for scroll-state.

[caugner]

LGTM, let's get this in.