Add positionAreaContainingBlock option

[jpzwarte]

Closes #411

Adds a positionAreaContainingBlock option (default: true) to control how position-area is polyfilled.

• true (default): The target is wrapped with a <polyfill-position-area> element that approximates the containing block created by position-area. Alignment is applied via justify-self/align-self on the target within that wrapper.
• false: No wrapper element is inserted. Instead, the polyfill resolves the position-area alignment to concrete inset values and applies them directly on the target. This avoids breaking selectors that depend on a direct DOM relationship (e.g. > target, + target, :nth-child()), but comes with trade-offs around inset overrides, self-alignment, and overflow alignment (documented in the README and position-area.html).

[netlify]

✅ Deploy Preview for anchor-polyfill ready!

Name	Link
🔨 Latest commit	d5340ea
🔍 Latest deploy log	https://app.netlify.com/projects/anchor-polyfill/deploys/6a31244c5390b400086f3b44
😎 Deploy Preview	https://deploy-preview-412--anchor-polyfill.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[netlify]

✅ Deploy Preview for anchor-position-wpt canceled.

Name	Link
🔨 Latest commit	d5340ea
🔍 Latest deploy log	https://app.netlify.com/projects/anchor-position-wpt/deploys/6a31244c0c98b200083128e5

[jamesnw]

Thanks for taking a look at this! I haven't done a full review, but wanted to note the questions I will be considering when reviewing.

1. What are the differences between having a containing block and not? (See https://www.oddbird.net/2025/02/25/anchor-position-area/#a-new-containing-block)
2. Can we programmatically discover when a containing block will have an impact?
3. How do we want to expose this? Is a global setting for the polyfill sufficient? Or maybe some way of disabling the containing block for certain elements? A data-anchor-position-polyfill-disable-cb attribute, or --anchor-position-polyfill-disable custom property? I don't like the idea of leaving cleanup for when the polyfill can be removed, but control could be useful. I also want to avoid something that people opt out of because it fixes one problem, and then get surprised by the other differences.

[jpzwarte]

So my reasoning for this PR is as follows:

1. It's just easier to position an element using position-area with a fallback:

  position-area: top;
  position-try-fallbacks: bottom;

2. As far as i can tell, not having a wrapper element doesn't impact positioning the element. It does impact sizing the element. So without the wrapper element, padding-left: 50% differs from the native implementation.
3. The wrapper element can break CSS and JavaScript (for manual slot assignments for example in custom elements).

So i kind of see this as a trade-off: you lose the relative sizes a containing block gives you, but you gain not having a wrapper element and having to take that into account in a web component based design system.

Since in our design system we so far always use CSS Anchor Positioning hand-in-hand with popover, it would like to have that trade-off.

To answer you questions:

1. See above
2. Good question; the first thing i can think of is detecting if percentages are used for padding etc.
3. I like your idea of signaling the polyfill to not use a wrapper element, but i'm not sure asking every developer to be aware of this is a good idea.

[jpzwarte]

As an experiment i've added an "auto" setting. This checks if the target has any styling that is affected by the containing block. It seems to work:

• "span-left top" is wrapped (uses padding-right: 50%)
• "center left" isn't