fix: add patchCSSOMto support setting anchor-name and position-anchor in JS - #447
fix: add patchCSSOMto support setting anchor-name and position-anchor in JS#447jpzwarte wants to merge 8 commits into
patchCSSOMto support setting anchor-name and position-anchor in JS#447Conversation
`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>
✅ Deploy Preview for anchor-polyfill ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for anchor-position-wpt canceled.
|
jamesnw
left a comment
jamesnw
left a comment
There was a problem hiding this comment.
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?
| // patch it never sees anchors that are wired up from JavaScript. | ||
| const PATCHED_PROPERTIES = { | ||
| anchorName: 'anchor-name', | ||
| positionAnchor: 'position-anchor', |
There was a problem hiding this comment.
Why not positionArea or other anchor-related properties?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
I think it's a matter of preference. If you run |
True, but where would we put an example for it? A new |
Done! |
2 participants
Fixes #445
patchCSSOM()(opt-in, exported from/fn) makesanchorNameandpositionAnchorsettable. It wraps the style getter to know which element a declaration belongs to, defines the two accessors on CSSStyleDeclaration, and writes the value into the element's style attribute; setProperty(), getPropertyValue() and removeProperty() take the dashed names as well. The values are also kept in a registry and re-applied at the start of each polyfill run, because any later CSSOM write reserializes the declaration block and drops them again.anchorNameinelement.stylebecomes true.CSS.supports('anchor-name: --a')is unaffected, and is what the README now recommends for feature detection.This PR also fixes inline styles inside a shadow root never being 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).