Safari Technology Preview 255 puts a button in select and spends fifteen fixes on line-clamp
Dex Halloran
Truncating text to a few lines has been copy-paste folklore for about as long as cards have had titles. You grab the snippet, it works on your test string, and you never look at it again until a float shows up below the cut and the whole thing falls apart. So yes, Safari Technology Preview 255 has a shiny forms feature. I'll get to it. The part I keep rereading is the fifteen separate line-clamp fixes.
The build, in one paragraph
STP 255 shipped on October 22 for macOS Golden Gate and macOS Tahoe, covering WebKit changes 322011@main through 323397@main. The new features are support for <button> in the native appearance of <select>, the side attribute on the SVG <textPath> element, the inline layout engine switched on for SVG text, the cross-origin-isolated Permissions Policy feature, transferring streams to an AudioWorklet, and a CSS keyframe animation editor in Web Inspector. One method is gone: the unimplemented document.implementation.createCSSStyleSheet(). The rest of the notes are mostly fixes, and there are a lot of them.
A button inside the select
The note is a single line: added support for <button> in the native appearance of <select>. It ships with no markup example, so I'm not going to make one up and pretend it's official. What I can tell you is that the Forms section brings two related fixes. :open had stopped matching a <select> while its base appearance picker was still showing, and a <select> was computing its selected option's style from outdated ancestor styles. Both are fixed. If you're building a customizable select in this preview and your :open styles dropped while the picker was still on screen, that was this bug.
Fifteen ways a clamp can leak
Here's the pile, sorted by what actually went wrong:
- Content past the clamp point stayed around. Block boxes after it stayed visible and kept taking up space. Floats after it stayed visible, and so did absolutely positioned elements whose containing block is an inline after the clamp point.
- Floats misbehaved. They made the
line-clampcontainer taller, added to its scrollable overflow, and painted past its block-end content edge. - The ellipsis landed in the wrong place. It could appear after a
<wbr>in awhite-space: nowrapline, on a line containing only a float, or refuse to hang withhanging-punctuation. line-clamp: autohad its own problems. It couldn't clamp between sibling blocks, it clamped inside a box with a set height, and it applied no clamp at all until the clamp point was found.
The other two: a line-clamp container now establishes an independent formatting context, and content before the clamp point no longer loses its lines when it hasn't changed.
That's a whole category of layout bugs getting worked through in one build (a clamp that leaks floats is not a clamp). If you wrote off line-clamp in this engine after a float broke it, test it again in this build.
Cascade fixes you'll feel in hand-written CSS
This one is small and it bugs me that it existed. font-family: initial was behaving like font-family: inherit, so you got the parent's font instead of the property's initial value. Fixed:
.plain-text {
font-family: initial;
}
initial and inherit are two different keywords that mean two different things, and a reset rule written with one was quietly getting the other.
The deeper cascade fixes: revert inside @starting-style was dropping @starting-style declarations from lower cascade layers. revert and revert-layer used the wrong cascade origin for visited and unvisited link styles, which wrongly disabled native appearance. :visited wasn't updating for links inside shadow trees. @scope now invalidates scope membership correctly when structural DOM changes affect the scoping root selector. And tree-scoped var() and custom function references inside an @function now resolve when the function is called from a :host rule. If you run layers, entry animations or shadow DOM in this preview, those are your bugs.
Two accessibility fixes for HTML you already write
Radio groups first. In HTML, putting required on any radio in a group makes the whole group required. The notes say WebKit now also exposes every radio in the group as required to assistive tech when only one carries the attribute:
<fieldset>
<legend>Shipping speed</legend>
<label><input type="radio" name="speed" value="standard" required> Standard</label>
<label><input type="radio" name="speed" value="express"> Express</label>
</fieldset>
Second, VoiceOver presses were dispatching a click event with an event.detail of 0. That's fixed too, and it's a good excuse to stop guessing the input device from event.detail. A click is a click.
There's also a popover fix in the HTML section: tabbing to a popover invoker now moves focus into the popover itself when the popover is focusable.
Where it stands
This is a preview build of one engine. The notes make no Baseline claim and I won't add one, so the <select> button support and the side attribute are things to try out on a test page, not to ship. One known issue to keep in mind: document.activeElement returns the <html> element instead of null in HTML documents with no body. The notes say other browsers behave differently and that this breaks the WebDriver Get Active Element command.
It's like a roguelike balance patch where the headline is a new item and the actual changes are fifteen fixes to the build you were already running. A solid 7 for features and a 9 for the cleanup.
Source: WebKit Blog (webkit.org)