v157 · css · anchor positioning
Deprecation is not removal
This proposal ships the singular names and deprecates the plurals — explicitly “but not removing them”. Those are different states with different consequences for your stylesheet, and only the last one breaks anything. Step through them, and check which state this browser is actually in.
Where this browser sits right now
| value | parses here | spelling | reading |
|---|
The four states a value moves through
the three words, precisely
Deprecated means “still works, stop writing it”. The value parses, applies, and behaves identically; you may get a console warning or a use-counter entry. No page breaks.
Aliased means the old name is mapped onto the new one. It parses, but it serialises as the new name — so getComputedStyle and CSSOM round-trips start returning a string you did not write. Tooling that string-matches on the old name breaks here, even though rendering does not.
Removed means the parser no longer recognises it. The declaration is dropped, the property falls back to its initial value, and anchored elements silently stop hiding themselves. This is the only state that changes what users see, and it is explicitly not part of this proposal.
what to actually do
/* Safe in every stage above, including stage 4. */
.tip {
position-visibility: anchors-visible; /* stages 1-3 */
position-visibility: anchor-visible; /* stages 2-4 */
}One extra line per rule makes the stylesheet stage-independent. There is no urgency — deprecation does not break pages — but there is also no reason to wait, since the dual-write costs nothing and removes the need to track which stage any given browser is in.