Opened the release notes with coffee and immediately reached for a scratch tab. STP 250 is not a maintenance drop.
Safari Technology Preview 250 shipped on 2026-08-13 for macOS Golden Gate and macOS Tahoe, covering WebKit changes 317507@main through 317934@main. It is a preview channel, one engine — but the CSS section alone has five new lines, and there is a Clipboard change with real day-job consequences.
Five CSS additions, in one build
Per the release, CSS gains support for text-decoration-inset, white-space-trim, wrap-inside, the content property on the ::marker pseudo-element, and the spaces value of ruby-overhang (with none now recorded as an alias for spaces).
Read that list twice. text-decoration-inset is the underline-position knob you have been asking for. white-space-trim and wrap-inside are text-flow controls. content on ::marker widens what a list marker can hold. ruby-overhang: spaces is East-Asian typography reaching into the Latin side of the flow.
The release does not give syntax bodies for any of these, so I am not going to type an example the notes do not confirm. What the notes do commit to is the parser accepting these names in this build. If you have been feature-detecting under @supports for any of them, you now have a lit-up target in one channel.
SVG through the Clipboard API
The Editing section adds copy and paste of image/svg+xml data via the Clipboard API. Per the release, the markup is sanitized on both read and write.
That is the line I care most about. Any page that lets a user paste artwork, or hand SVG between two tabs of the same app, gets a real path instead of the "wrap it in a <img> and hope" hack. Sanitization on both ends is the important half: the browser strips the payload that arrives from a foreign source, and it strips again on the way out. If you have been shipping a canvas or diagram editor that talks in SVG, this is the primitive you have wanted.
Do not read this as "shipping everywhere yet." One preview channel, one engine. Wire it up, confirm the round-trip in this build, then feature-detect at runtime.
A VoiceOver line-break repair on textarea
The Accessibility section fixes a bug I have hit and cursed at in real life. Per the release, VoiceOver no longer reads a stray newline or skips lines when navigating a <textarea> whose value ends in a line break.
That is the one every form with a "notes" field runs into. A user hits return, submits, comes back, VoiceOver announces phantom whitespace or jumps rows. The engine now handles the trailing newline the same way sighted users see it: as the terminator, not as extra content.
This one needs no gating. It is a behaviour repair. If you build long-text forms, retest them in this preview build.
A small JavaScript aside
Two JavaScript entries land in the same build. using and await using declarations from the Explicit Resource Management proposal, along with Symbol.dispose, DisposableStack and AsyncDisposableStack. And Iterator.zip() and Iterator.zipKeyed() from the Joint Iteration proposal. These sit outside the HTML/CSS beat this site covers, so read them from the linked spec pages. Worth flagging that they are here in the same build as the CSS above.
One name gone: text as a color value
Per the release, the non-standard text color value has been removed. The documented replacement is canvastext. If you have older stylesheets or a design token that still resolves to text, swap it. canvastext is a standard system color, so the substitution is one-for-one at the syntactic level.
Grep your codebase for : text; in a CSS context before you find out in production.
Which browsers, and how far
The release makes no Baseline claim on any of the items above, and neither will I. STP is Safari's preview channel. That means the parser knows the name in this engine, in this build; it does not mean the feature has landed in Chromium or Gecko, or that a stable Safari has picked it up. Check the interop dashboards and the linked specs before you write more than a scratch rule, and gate live use behind @supports (for the CSS) or a runtime capability check (for image/svg+xml on the clipboard).
What I'm watching next
The two lines I want to see match across engines are text-decoration-inset and white-space-trim. Underline positioning and text-flow trimming are both features you want to author the same way in every browser or not author at all. If Chromium and Gecko pick up the same names with the same behaviour, hand-authored typography gets a small quiet upgrade this year. If not, they stay in the scratch-page bin. Either way, the SVG clipboard round-trip is the one I am wiring into a real tool this week.
