Safari Technology Preview 252 adds @supports named-feature(), unprefixed user-select and two accessible-name fixes

I wired up the small pieces of this release before writing anything, and the ones I wanted most were the two I could not fake before. Named-feature() as a test, and a way to read a rule's own condition back off the OM. Not a headliner drop, but it clears a couple of stubborn corners.

Safari Technology Preview 252 was published 11 September 2026 by Jon Davis and pulls in WebKit changes between 319252@main and 320112@main. Preview channel, one engine, no Baseline claim on any of this.

What actually landed

Five items, all small, all hand-authorable:

• @supports named-feature(...) now parses. A test aimed at behaviours that were previously undetectable — the ones a property/value probe or a selector() body could not reach.
• CSSConditionRule.supports and CSSMediaRule.matches are exposed to the CSSOM.
• The unprefixed user-select property is supported.
• text-decoration-inset now accepts percentage values.
• Two accessible-name fixes. A display: contents element no longer includes text from its siblings in its accessible name. And list marker text no longer leaks into accessible names or values that requested the text without markers.

What I'm watching next

Named-feature() is the one to prototype under a @supports block. It's the escape hatch we haven't had — where a property/value pair or a selector() test can't answer whether a behaviour is on. Cross-engine landing is the next signal to watch. The two accessible-name fixes are the ones I'll re-run screen-reader spot checks against, because those are the kind of quiet correctness change that only shows up when you go looking.

Comments

[Raknaos]

The honest read of this release is that the two accessible-name fixes are the biggest behavioural change and the least testable one. @supports named-feature() eventually closes that gap for engine features, but name computation lives in the platform layer above the engine - a query that answers "does this browser compute names this way" isn't something @supports can express even after it lands widely.

Which is why the screen-reader spot check stays in the loop: for the display: contents case the only reliable detection today is a runtime probe or shipping behind a flag and watching the results. Curious what you think the cross-engine story is here - if only WebKit implements named-feature() for a year, do you use it as a WebKit-only escape hatch, which quietly reintroduces the prefix problem it was meant to solve?