https://webkit.org/blog/15063/webkit-features-in-safari-17-4/ [pixel] WebKit [ ] * Downloads * [ ]Feature Status + CSS Features + Standards Positions * [ ]Documentation + Web Inspector + Tracking Prevention * [ ]Policies + Project Goals + Bug Prioritization + Bug Report Guidelines + Code Style Guidelines + Commit and Review Policy + Feature Policy + Security Policy + Tracking Prevention Policy * [ ]Contribute + Getting Started + Contributing Code + Testing Contributions + How to Report Bugs + GitHub Repository * [ ]Blog + News Posts + CSS Posts + Contributing Posts + Privacy Posts + Performance Posts + JavaScript Posts + Standards Posts + Web Inspector Posts + Safari Technology Preview Posts * [ ] WebKit Features in Safari 17.4 Mar 5, 2024 by Jen Simmons and Jon Davis [ ] Contents + Architectural improvements + Web Apps + Form elements + CSS + Web API + JavaScript + Media + SVG + WebGL + Web Assembly + Web Inspector + Changes to Safari + Safari Extensions + Web Authentication + Bug Fixes and more + Updating to Safari 17.4 + Feedback Just like Safari 15.4 and Safari 16.4, this March's release of Safari 17.4 is a significant one for web developers. We're proud to announce another 46 features and 146 bug fixes. You can experience Safari 17.4 on iOS 17.4, iPadOS 17.4, macOS Sonoma 14.4 beta, macOS Ventura, macOS Monterey, and in visionOS 1.1 beta. Architectural improvements It's always exciting to ship new features that you can use while building websites and web apps for your users. WebKit engineers also work on many important projects beyond implementing new web platform features. Recently, much effort has gone into multiple infrastructure projects that strengthen WebKit for the long-term. We completed the final installment of our multi-year long rewrite of our inline layout engine (more on that later). We built two new iOS frameworks with hundreds of new APIs to support functionality used by web browsers, including multiprocess, JIT, and advanced keyboard & touch event access -- and we are pivoting WebKit to use these new frameworks. We're working on several other large projects that deepen security and privacy. And we've been hard at work to make Safari even faster. For many years, Safari has held the crown of the world's fastest browser. It's important to us to keep pushing the boundaries of speed, as the websites you build continue to get more complex. Hundreds of recent changes result in Safari 17.4 showing a significant performance bump. Web Apps Safari 17.4 brings two improvements to web apps on Mac. First, Safari adds support for the shortcuts manifest member on macOS Sonoma. This gives you a mechanism in the manifest file for defining custom menu commands that will appear in the File menu and the Dock context menu. Web Kittens web app open on macOS, with the File menu showing and four custom shortcuts listedOn Mac, our Web Kittens web app includes four shortcuts. You can see them listed in the File menu: New Kitten, Discover, Messages, and Notifications. They each open a menu item by going to the appropriate URL. A web app shortcut consists of a name, (the words you'd like to appear in the menu), and a url. When a user activates the command, it opens the specified URL inside the web app. "shortcuts": [ { "name": "New Kitten", "url": "/new-kitten" }, { "name": "Discover", "url": "/discover" } ] Users can set up custom keyboard shortcuts for app menu commands in System Settings > Keyboard > Keyboard Shortcuts > App Shortcuts. By default, macOS does not assign web app shortcuts any keyboard commands. Second, Safari 17.4 now supports the categories manifest member on macOS Sonoma. This member provides you with a mechanism for telling the browser which categories your web app belongs in. On Mac, when a user creates a Launchpad folder that contains web apps, the folder is automatically named accordingly. Launchpad on macOS showing two app icons in a group titled Social Networking Form elements Switch control The switch is a popular interface for many use cases, but until now, there was no easy way to put a switch on the web. Instead developers might use a checkbox input field, remove the visual look of the checkbox with appearance: none, and write custom styles to create something that looks like a switch. Now, with WebKit for Safari 17.4, HTML supports a native switch. If you code , the browser will simply create a switch for you, and map it to role=switch and related ARIA features. Try this demo in Safari 17.4. Currently, in other browsers you will see three checkboxes. Extending the current HTML checkbox provides several benefits and honors the W3C's HTML Design Principles. First, this design degrades gracefully -- which means you can use today. Browser that have support will show a switch, while browsers that do not have support will show a checkbox. No user will get a broken experience, and you don't have to wait until all of your users have a browser with support in order to utilize this on your website or web app. This design also does not reinvent the wheel. It matches the way form controls have always worked on the web, and feels just like the code you're used to. It's an incremental evolution of the web. And as a simple solution, it avoids needless complexity. The accent-color property can be used to change the background color of the switch in the "on" state. And, exactly like other form controls, you can use appearance: none to remove the system default styling and apply your own, perhaps while leveraging :before and :after. In the future, there will likely be multiple pseudo-elements to make it even easier to style the switch with your custom styles. You can try out ::track and ::thumb in Safari Technology Preview today and let us know what you think of this approach. See how they work in this demo, after enabling the "::thumb and ::track pseudo-elements" feature flag. (These pseudos are waiting to ship until there is a more comprehensive plan for styling form controls proposed, discussed and resolved on at the CSS Working Group.) Vertical writing modes From the beginning, the web has always been interactive. Even before any method of custom styling was available, form controls and input fields provided the means for users to communicate back to the website and to each other. The web was also originally designed in an era when the Latin alphabet (used by many languages, including English) was the presumed default, with its horizontal top-to-bottom writing mode. For thirty years, form controls have presumed a horizontal writing mode. Typesetting in a vertical writing mode for languages like Chinese, Japanese, Korean, and Mongolian did not include vertical form controls. Now that's changed. Starting in Safari 17.4, vertical form controls are supported. This includes meter, range, progress and other form controls that could make for great UI in any language when laid out in a vertical format. [vertical-form-controls-light]Try this demo of vertical form controls in a browser that has support. Horizontal Rules inside Select You can use an
element (a horizontal rule) inside a on macOS. CSS Inline Layout One of the infrastructure projects that's been underway in WebKit during the last several years is the complete rewrite of our inline layout engine. Safari 17.4 marks the completion of this project and the retirement of the twenty-one year-old legacy line layout engine. Inline layout is integral to displaying content on the web. It determines the size and layout -- wrapping, justification, spacing, and baseline alignment -- of all text and other inline-level content. As developers, we often focus on the invisible block boxes on a web page and write CSS to layout those boxes using Flow, Tables, Flexbox or Grid. The content inside those boxes is placed using complex inline layout algorithms that developers often don't need to think much about. We've been shipping our new inline layout engine incrementally for many years. As more and more of the new engine was complete, more and more of the content on web pages was positioned by the new engine. This means users have been benefiting from WebKit's new inline layout engine for a while. The legacy system was only triggered if there were something that hadn't been yet implemented in the new engine. The last major step needed was the reimplementation of Ruby -- and now it's also a proper inline layout feature, fixing past inconsistencies. Projects like these can be disruptive. Often browser teams will choose to not ship any new features while a multi-year rewrite project is in progress. WebKit instead chose to keep shipping new features, often implementing them twice -- once in the legacy line layout engine, and again in the new inline layout engine. Now that this work is done, we no longer have to implement anything twice. This work also let us go through a large number of bugs reported on bugs.webkit.org, confirm they are no longer a problem, and close them as fixed. We're excited for WebKit's future with this new engine. This investment results in increased interoperability by aligning to the latest web standards, fewer inline layout bugs, better performance, improvements to stability, and the ability to implement new features far more easily. The completion of inline layout also marks the beginning of rewriting the layout engine for other formatting contexts, starting with Flexbox. Align content everywhere When Flexbox shipped, it brought a powerful new tool to the web -- box alignment. The align-content property made it possible to easily vertically center content inside a box! Or you could use it to align content to the bottom to the box, to align baselines of text, and more. When CSS Grid shipped, box alignment became possible in a second layout mode. Since 2017, you've been able to align the direct children of both Flexbox and Grid containers. Now, we are proud to be the first browser shipping support for align-content inside two more formatting contexts -- block layout and table layout. This means if all you want to do is align a box's content in the block direction, you don't need to involve Flexbox or Grid. Plus, you can now mix alignment with floats, and you can use it inside table cells. div { align-content: center; } /* one-line vertical centering */ In addition, we updated the handling of align-content and justify-content on scroll containers in WebKit for Safari 17.4. Now, for example, you can use CSS to set the initial scroll position to the end rather than the start of the content. div { overflow: auto; align-content: unsafe end; } /* end-aligned scroller */ Be sure to test alignment on scroll containers across browsers, as many are still in the process of updating to the specified behavior. Those that have not yet updated may clip content. CSS Scoping Websites today can be complex, with large teams working across multiple projects, relying on pattern libraries or frameworks to keep everything organized and consistent. It can become tough for large teams to handle how their CSS cascades. Tools like Cascade Layers and :has() have changed the game, allowing developers to apply styles more masterfully. Yet, developers often want a way to scope styles to the individual component they're working on, without worrying about the big picture or preventing unintended consequences. CSS Scoping was created to provide several more powerful options for organizing and structuring CSS. (Note, there have been many debates over many years on how style scoping might work. Search results for "CSS scoping" often yield old, unimplemented or completely different ideas.) WebKit for Safari 17.4 adds supports the @scope rule and expands the capabilities of the :scope pseudo-class. Scoping changes how the cascade works in some surprising ways, so do be sure to read about its impact before deploying widely. If your project is making heavy use of components, constructed independently and loaded in random order, scoping can help you by ensuring certain styles only apply to the contents of a specific element, and never to anything else on the page. By default, all CSS on a project applies universally. It has a "scoping root" of . And the :root pseudo-element refers to the root element in the DOM -- the html element. CSS Scoping lets you use

This is 4rem text.

This will not be styled by the CSS above.

In this case, because
is the direct parent of

This is 4rem text.

You can try this demo in a browser with support. White space and text wrap For years, the white-space property in CSS has provided a mechanism for doing two things at once: 1) defining whether and how white space is collapsed, and 2) defining whether and how lines wrap. The CSS Working Group has since noted that this was likely a mistake, to handle two different qualities in one property. With the introduction of text-wrap, the CSSWG has rethought how the long and shorthand versions of these properties combine into an architecture that makes more sense and gives us needed flexibility. Now the white-space property is a shorthand for two new longhand properties: white-space-collapse and text-wrap-mode, both added in WebKit for Safari 17.4. These longhands let you change the collapsing and wrapping modes independently, each without affecting the other. The white-space-collapse property controls how white space is collapsed. By default, it's set to collapse, causing strings of multiple spaces to become a single space. You can change the value instead to preserve in order to keep all the spaces, or use other the values: preserve-breaks, preserve-spaces, or break-spaces. These values all behave as they have for years with the white-space property. The new text-wrap-mode property provides a mechanism for setting whether or not text should wrap. The wrap value turns it on, and the nowrap value turns it off. This work sets the stage for the text-wrap shorthand and it's longhands text-wrap-style and text-wrap-mode, some of which you can currently test in Safari Technology Preview. Percentages in spacing WebKit for Safari 17.4 adds support for percentages in letter-spacing and word-spacing. This lets you define spacing as a percentage of the element's font-size -- and keeps tracking the font-size even when it grows or shrinks on descendant elements. Styling grammar and spelling errors WebKit for Safari 17.4 adds support for the ::spelling-error and ::grammar-error pseudo-elements. These make it possible to create your own custom styling for text that is marked by the browser as misspelled or grammatically incorrect. Alt text for generated content The vast majority of content on the web is communicated through HTML, but CSS does have the ability to insert content into the page. Until now, sometimes this kind of content could not be made accessible. Now in WebKit for Safari 17.4, you can provide alternative text with accessible content fallback -- content: "foo" / "alt-text"; For example, perhaps we want to prefix certain links with the little i icon to let users know this item leads to more detailed information. That symbol might be read by screenreader as "Circled Latin Small Letter I" or "Information source combining enclosing circle", neither of which do a good job communicating the intended purpose. Perhaps a better experience would be to simply hear "Info:". .info::before { content: "i" / "Info:"; } Previously, the -webkit-alt property served this function. It has been deprecated in favor of the new content alt text syntax. The new syntax is also more expressive as it allows for cascading, and allows you to chain multiple strings and attr() as alternative text. Transitions When CSS Transitions were created, they allowed authors to create a gradual timed transition between old and new values by interpolation. Sometimes, however, interpolation is not possible. For example, there's no meaningful intermediary value between float: left and float: right, so, transitions ignored these properties. They simply jumped from the first state to the second immediately, without any ability to define when the jump should happen. Yet, web developers have wanted a way to at least be able to define when the transition should happen for discrete properties. So the CSS Working Group figured out a way to make that possible. Now, you can tell the browser that you want an element to be capable of transitioning discrete property values, which lets you control their transition timing using the easing functions. WebKit for Safari 17.4 adds support for the transition-behavior property. The transition-behavior: allow-discrete rule lets you enable transitions between discrete property values, so that you can control their timing via transition. li { list-style: disc; color: blue; transition: all 2s, list-style 0.5s step-end; transition-behavior: allow-discrete; } li:hover { list-style: square; color: red; } Try this demo code in a browser with support. Toggle transition-behavior off to see the difference. :has() The :has() pseudo-class provides tremendous value. We keep making it more and more powerful by adding support for additional pseudo-classes within :has(). WebKit for Safari 17.4 adds support for :has(:any-link), :has(:link), and :has(:-webkit-any-link), making it possible to select an element depending on whether or not it contains a link. And more WebKit for Safari 17.4 adds support for CSS custom properties to the ::backdrop pseudo-element, allowing variables to be applied to the backdrop behind dialog elements and other top layer items. WebKit for Safari 17.4 also adds offset-position support for circle() and ellipse(). And WebKit for Safari 17.4 makes -apple- prefixed pseudo-elements no longer valid. Web API This release of Safari adds support for an assortment of small Web API additions that give you extra tools in your developer toolkit. With support for the element.checkVisibility() method, you can determine the visibility of an element across a variety of conditions including how CSS properties such as display, visibility, and opacity are applied. WebKit for Safari 17.4 also extends its Declarative Shadow Root support. The Element.prototype.setHTMLUnsafe(), ShadowRoot.prototype.setHTMLUnsafe(), and Document.parseHTMLUnsafe() methods, as well as the ShadowRoot clonable property are now available. The setHTMLUnsafe() methods work similar to setting an element's innerHTML property, enabling unsanitized DOM tree mutation but with additional support for declarative shadow roots. The parseHTMLUnsafe() method similarly parses unsanitized HTML with declarative shadow root support and returns a document. And the clonable read-only boolean property allows you to detect if a ShadowRoot is clonable. WebKit for Safari 17.4 adds support for the CustomStateSet interface for custom element state management. This interface includes methods to add(), delete(), or detect if the element has() a given state, and more. Importantly, these states added to a custom element can be styled using the :state() pseudo-class by users of the custom element. The DOMMatrixReadOnly interface now supports the scaleNonUniform() method that creates a new DOMMatrix scaling on X, Y, and Z axes. The X axis scaling factor must be specified, but the Y and Z axes default to 1. The scaling is centered at the given origin that defaults to (0, 0, 0). Lastly, WebKit for Safari 17.4 adds support for AbortSignal.any() giving you a convenient way to combine abort signals such as user input (e.g. a user clicks a cancel button) and a timeout to send an abort signal to an async operation. JavaScript New JavaScript features in Safari 17.4 add new expressiveness and convenience with promise resolvers, improved internationalization formatting, ArrayBuffer ownership management, and Array grouping features. WebKit for Safari 17.4 adds support for the Promise.withResolvers static method. It allows developers the convenience of creating a promise and configure the resolution and rejection handlers after it has been created. The method returns the promise along with the resolution and rejection functions. const { promise, resolve, reject } = Promise.withResolvers(); The TimeZoneOffset format is now available for Intl.DateTimeFormat. It allows you to specify the difference of the local time to UTC time in positive or negative hours and minutes depending on whether the local time is ahead or behind. new Intl.DateTimeFormat("en-US", { dateStyle: 'long', timeStyle: 'long', timeZone: '-0800' }).format(new Date()) Additionally, Number.prototype.toLocaleString and Intl.NumberFormat have been updated so the string representation correctly aligns with recent specification changes. There's also new expressive API for managing the concept of ownership for ArrayBuffers. ArrayBuffer.prototype.transfer creates a new ArrayBuffer with the same contents and properties as the target ArrayBuffer (such as being resizable) and detaches it from the original ArrayBuffer. You can use ArrayBuffer.prototype.transferToFixedLength() to guarantee a non-resizable ArrayBuffer with the same content as the buffer. ArrayBuffer.prototype.detached will tell you if the buffer has been transferred and is detached. WebKit for Safari 17.4 also adds the Array grouping feature that includes Object.groupBy and Map.groupBy methods. These methods give you powerfully simple tools for grouping datasets. const todos = [ { task: "Water the flowers", context: "home", estimate: "5 minutes" }, { task: "Get the TPS report done", context: "work", estimate: "45 minutes" }, { task: "Find new insurance", context: "home", estimate: "180 minutes" }, { task: "Fix a website bug", context: "work", estimate: "25 minutes" }, { task: "Answer emails", context: "anywhere", estimate: "10 minutes" } ]; let contextual_tasks = Object.groupBy(todos, ({ context }) => context); console.log(contextual_tasks); let tasks_by_time = Map.groupBy(todos, ({ estimate }) => { return parseInt(estimate.split(' ')[0]) < 15 ? "short" : "long"; }); console.log(tasks_by_time); Media Additional codecs WebKit for Safari 17.4 adds support for several audio and video codecs. First, WebKit for Safari 17.4 on iOS, iPadOS and in visionOS adds support for WebM. While the WebM container (with both the VP8 and VP9 video codecs) has been fully supported on macOS since Safari 14.1, support on iOS and iPadOS was limited to VP8 in WebRTC. Now, WebM is fully supported everywhere. The Vorbis audio codec is also now supported in WebKit on iOS 17.4, iPadOS 17.4 and in visionOS 1.1. And WebKit for Safari 17.4 expands what WebCodecs can do with the addition of support for the HEVC codec. Source prioritization When support for video embedding arrived in HTML5 with the