fix: add `patchCSSOM`to support setting anchor positioning properties in JS by jpzwarte · Pull Request #447 · oddbird/css-anchor-positioning

jpzwarte · 2026-07-25T11:10:09Z

Fixes #445

patchCSSOM() (opt-in, exported from /fn) makes every anchor positioning property the polyfill supports settable from JavaScript: anchor-name, anchor-scope, position-anchor, position-area, and the position-try properties. position-visibility is left out, as the polyfill doesn't support it. It defines each on CSSStyleDeclaration and stores the value in the custom property the polyfill shifts that declaration into internally — the browser can't drop a custom property, and it's already what the polyfill reads back. setProperty(), getPropertyValue() and removeProperty() take the dashed names as well.

cascadeCSS then restores those declarations to the property they were set on, before anything parses them, so a value set through the CSSOM is indistinguishable from one written in a stylesheet. That's what makes the properties beyond anchor-name/position-anchor work at all, and it keeps the CSSOM out of every parser — no special cases in parse.ts, position-area.ts or fallback.ts.

'anchorName' in element.style becomes true once it has run. CSS.supports('anchor-name: --a') is unaffected, and is what the README now recommends for feature detection.

Two bugs fixed along the way, both of which predate the CSSOM work:

Inline styles inside a shadow root were never collected: fetchInlineStyles() only searched document. It now searches the polyfill roots too — both, since a shadow-scoped run still needs its host and any light-DOM anchors.
transformCSS() corrupted an element's style attribute whenever the polyfill generated a fallback rule for that element's inline styles. It pulled the declarations back out with a fixed-length slice, which breaks as soon as anything else shares the block, writing a mangled selector into the attribute and losing the element's real styles. Generated rules now go into a stylesheet of their own. This was already reachable from plain HTML (<div style="position-try-fallbacks: --flip">), where the fallback silently never applied either.

Adds demos to index.html and shadow-dom.html.

`anchor-name` and `position-anchor` assigned from JavaScript are dropped by the CSSOM in a browser without native support, so nothing lands in the `style` attribute the polyfill reads. The demo wires up its anchor at runtime the way a design system component would, and does not work as a result. Refs oddbird#445 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

netlify · 2026-07-25T11:10:14Z

✅ Deploy Preview for anchor-polyfill ready!

Name	Link
🔨 Latest commit	`e1bdda2`
🔍 Latest deploy log	https://app.netlify.com/projects/anchor-polyfill/deploys/6a83264fb310930008f687a0
😎 Deploy Preview	https://deploy-preview-447--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 · 2026-07-25T11:10:14Z

✅ Deploy Preview for anchor-position-wpt canceled.

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

jamesnw

Mostly conceptual questions at this point-
Idea- instead of writing the unsupported values to the style tag, could we shift the values to custom properties? I think that would sidestep a lot of this. We could do it like the shifted properties in cascade.ts, so like --anchor-name-${INSTANCE_UUID}, and then it might just work when we need to read it.

Does this change make it work better for Lit, for instance?

This is useful for non-shadow DOM things, correct? It might be worth not tying the examples together.

Would it be possible to expose this as an option when the polyfill is run, or does it need to be applied as a separate step, so that the application can do some work before the polyfill can be run?

jamesnw · 2026-07-27T15:34:28Z

+// patch it never sees anchors that are wired up from JavaScript.
+const PATCHED_PROPERTIES = {
+  anchorName: 'anchor-name',
+  positionAnchor: 'position-anchor',


Why not positionArea or other anchor-related properties?

Because anchor-name and position-anchor are the dynamic parts that i'm setting from Lit. Example:

<sl-button id="button">Button</sl-button> <sl-tooltip for="button">Tooltip</sl-tooltip>

Which results in:

<sl-button id="button" style="anchor-name: --sl-tooltip-1">Button</sl-button> <sl-tooltip for="button" style="position-anchor: --sl-tooltip-1">Tooltip</sl-tooltip>

Everything else is part of :host.

I could add more properties of course, but i'm not sure its worth it?

Perhaps including at least position-area as well is a good idea. I can at least think of a web component where you could specify where it is anchored. But where do you stop?

There are only a handful of new properties for anchor positioning, and I'd rather just support them all.

See 5b315b0. This was more than just adding more properties to PATCHED_PROPERTIES:

patchCSSOM works by stashing whatever you assign into a private custom property, so el.style.positionArea = 'top' really lands in the style attribute as --position-area-<id>: top. Nothing else in the polyfill knows to look there — the two properties that already worked did so because two spots in the parser had been hand-taught to recognise that private spelling.

So rather than hand-teach five more spots (which would have made every author rule match twice, since the cascade leaves both spellings behind), this commit adds one step to cascadeCSS that renames the private property back to the real one before anything parses it; from there the CSSOM-set value is indistinguishable from CSS the author wrote, and every existing parser handles it for free.

The position-try properties also had to be added to the shifted list so their values survive being written back to the style attribute, and that in turn exposed a bug where transformCSS mangled that attribute whenever the polyfill generated a fallback rule for an inline style.

jpzwarte · 2026-07-28T13:04:32Z

Would it be possible to expose this as an option when the polyfill is run, or does it need to be applied as a separate step, so that the application can do some work before the polyfill can be run?

I think it's a matter of preference. If you run polyfill() after HTML has rendered, then it's too late. So in that case you would need to call patchCSSOM() before it. Otherwise it could be an option.

jpzwarte · 2026-07-28T13:05:33Z

This is useful for non-shadow DOM things, correct? It might be worth not tying the examples together.

True, but where would we put an example for it? A new cssom.html page?

jpzwarte · 2026-07-28T13:06:10Z

Idea- instead of writing the unsupported values to the style tag, could we shift the values to custom properties? I think that would sidestep a lot of this. We could do it like the shifted properties in cascade.ts, so like --anchor-name-${INSTANCE_UUID}, and then it might just work when we need to read it.

Done!

jamesnw

This is looking pretty close, I think!

This is useful for non-shadow DOM things, correct? It might be worth not tying the examples together.

True, but where would we put an example for it? A new cssom.html page?

It can just be added to index.html. I know it's super long, and eventually it would be nice to have a nicer way to add demos.

jamesnw · 2026-08-03T14:38:43Z

+// patch it never sees anchors that are wired up from JavaScript.
+const PATCHED_PROPERTIES = {
+  anchorName: 'anchor-name',
+  positionAnchor: 'position-anchor',


There are only a handful of new properties for anchor positioning, and I'd rather just support them all.

into fix/445-cssom-not-working

jpzwarte and others added 2 commits July 25, 2026 12:17

Add patchCSSOM

38e3646

Update README

b35753d

jpzwarte marked this pull request as ready for review July 25, 2026 11:48

jpzwarte added 2 commits July 27, 2026 12:23

Revert feature check doc change

8d2e506

Tweaks to docs

98a98b0

jamesnw requested changes Jul 27, 2026

View reviewed changes

jpzwarte added 2 commits July 28, 2026 14:32

Remove SVGElement

35979ae

Add doc about performance hit

45be448

Shift CSSOM properties to CSS variables

82b6875

jamesnw requested changes Aug 3, 2026

View reviewed changes

jpzwarte added 5 commits August 15, 2026 10:38

Merge branch 'main' into fix/445-cssom-not-working

40caad4

Support all properties instead of just anchorName and positionAnchor

5b315b0

Be less verbose in comments

9eca642

Expand the isDeclaration util function to include an optional property

56be5d6

Revert regexp back to simpler solution

c14913f

jpzwarte changed the title ~~fix: add patchCSSOMto support setting anchor-name and position-anchor in JS~~ fix: add patchCSSOMto support setting anchor positioning properties in JS Aug 15, 2026

jpzwarte and others added 2 commits August 15, 2026 12:21

Add example of patchCSSOM to index.html

3ac1917

Merge branch 'main' of https://github.com/oddbird/css-anchor-positioning

e1bdda2

into fix/445-cssom-not-working

Uh oh!

Uh oh!

Conversation

jpzwarte commented Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify Bot commented Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for anchor-polyfill ready!

Uh oh!

netlify Bot commented Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for anchor-position-wpt canceled.

Uh oh!

jamesnw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jamesnw Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

jpzwarte Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

jpzwarte Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

jamesnw Aug 3, 2026

Choose a reason for hiding this comment

Uh oh!

jpzwarte Aug 15, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jpzwarte commented Jul 28, 2026

Uh oh!

jpzwarte commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jpzwarte commented Jul 28, 2026

Uh oh!

jamesnw left a comment

Choose a reason for hiding this comment

Uh oh!

jamesnw Aug 3, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jpzwarte commented Jul 25, 2026 •

edited

Loading

netlify Bot commented Jul 25, 2026 •

edited

Loading

netlify Bot commented Jul 25, 2026 •

edited

Loading

jpzwarte commented Jul 28, 2026 •

edited

Loading