TL;DR: Safari Technology Preview 255, released October 22, 2026, adds support for <button> inside the native appearance of <select> — part of the ongoing rollout of CSS's customizable select feature (appearance: base-select), which Safari shipped in version 27 back in September. The change lets the select's trigger be a genuine <button> element instead of an opaque internal control, giving developers more predictable styling and event behavior when they opt a select into the fully styleable picker.
Customizable select has been one of 2026's more welcome form-control changes precisely because it replaces years of JavaScript dropdown libraries with a native element that keeps built-in keyboard handling and accessibility for free. Chrome and Edge shipped it in version 135; Safari followed in 27.0 this September; Firefox still treats it as experimental, off by default. Teams building production forms as part of disciplined web development services at YuSMP have been watching this rollout closely, because a feature that only half the engines support reliably needs a progressive-enhancement plan, not a hard dependency.
STP 255 is a preview build, not a stable Safari release, so this specific refinement hasn't reached anyone's production browser yet. But it's a concrete signal of where the spec is heading next, and it's worth understanding now rather than after it ships.
According to WebKit's release notes, the Forms section lists one line under this update: support for <button> in the native appearance of <select>. That's a narrow, specific addition sitting inside a much larger feature — customizable select, which Safari enabled by default back in version 27.0 this September. The base feature lets a developer opt a select into appearance: base-select and then style the trigger, the picker popover, the option list, the arrow icon, and the checkmark with ordinary CSS, while the browser still owns keyboard navigation, focus management, and form submission behavior behind the scenes. This release refines one specific part of that picture: what element type the trigger itself is actually allowed to be.
Before this change, the clickable part of a customizable select — the piece showing the current value and opening the picker when activated — was an internal part of the select's own rendering, not a distinct element you could reason about with ordinary HTML semantics. Letting it be an actual <button> closes that gap. A <button> comes with a settled, well-tested set of behaviors: default keyboard activation on Space and Enter, a predictable focus ring, and unambiguous exposure to assistive technology as a button. Developers who have spent years building custom dropdown widgets know this problem well — reimplementing a trigger's semantics from scratch is exactly the kind of detail that's easy to get subtly wrong, which is the whole reason customizable select exists as a native alternative to JavaScript component libraries in the first place.
Nothing in production changes today — Safari Technology Preview is a developer-facing channel that doesn't dictate what stable Safari or other browsers do on any particular timeline, and this is one Forms-section line among dozens of changes in the release. If you're already experimenting with appearance: base-select, there's no action required yet; the underlying behavior you get from the stable Safari 27 release is unaffected. If you're evaluating whether to adopt customizable select for a production form now, keep treating it as progressive enhancement exactly as WebKit and the spec recommend: a select with appearance: base-select that an unsupporting browser doesn't understand falls back cleanly to the ordinary native dropdown, so Firefox users today simply get the plain OS picker while Chrome, Edge and Safari users get the styled version. Don't ship styling that assumes <button>-specific behavior from the trigger until it reaches a stable release channel.
Safari Technology Preview releases roughly every two weeks and functions as a preview of what's likely to land in a future stable Safari version — but STP changes don't carry a committed ship date, and not every STP experiment reaches a stable release unchanged. The realistic timeline: watch for this specific change (or a revised version of it) to appear in WebKit's changelog for an upcoming Safari point release, most plausibly in the Safari 27.x line given that customizable select itself shipped in 27.0 two months ago. Cross-browser parity is a longer story — Chrome and Edge have supported the base feature since version 135, but Firefox's implementation remains experimental and disabled by default, so a fully interoperable, Baseline-ready customizable select across all major engines is still some distance off.
It's a CSS feature that opts a native <select> element into a fully styleable state — letting developers style the trigger, picker popover, option list, and icons with CSS — while the browser retains built-in keyboard navigation, focus handling, and accessibility behavior.
No. It shipped in Safari Technology Preview 255 on October 22, 2026, a developer preview channel. It has not reached a stable Safari release yet.
Chrome and Edge have supported it since version 135. Safari shipped it in version 27.0 in September 2026. Firefox's implementation remains experimental and is disabled by default.
Only as progressive enhancement. Browsers that don't recognize the declaration render an ordinary, fully usable native select, so unsupported browsers degrade gracefully rather than breaking.
A real <button> carries settled keyboard activation, focus, and assistive-technology semantics by default, which is more reliable than reimplementing those behaviors on a generic internal control.
Primary source: WebKit's Release Notes for Safari Technology Preview 255. Independent coverage confirming the release date and feature list: BrowserHow's STP 255 rundown.