Adopting Safari Technology Preview 256 Without Breaking Stable Safari
A technical walkthrough of how to take what lands in Safari Technology Preview 256 without regressing stable Safari users. The post separates what the public record confirms from what it doesn't. Confirmed: Apple publishes per-build WebKit release notes grouped by area, and a community write-up compares TP 256 against TP 255. Not confirmed at time of writing: the itemised diff, the WebKit build identifier, which items are on by default versus behind a preference, and whether any item has been reverted on trunk. So you extract those yourself instead of trusting a summary, including this one. What the video covers: - Why a preview build is a signal about where WebKit trunk is heading, not a support matrix entry - Saving the adjacent release-note pages for builds 255 and 256 and diffing them mechanically with a small Node script that classifies items into features, behavior changes, vendor-prefixed work and fixes - Cross-checking every added item against the WebKit commit log, MDN browser-compat-data and the WPT dashboard - Reading pref state from the release-note wording: enabled by default, behind a preference, or an ambiguous bare 'added support' - The adoption rule: adopt a preview feature only when a second engine ships the same behavior, backed by behavior-based feature detection and a tested fallback - A WebKit CI lane that catches the regressions preview-driven code actually produces Full write-up: https://hackyjs.com/posts/adopting-safari-technology-preview-256-without-breaking-stable-safari