April 18, 2024

WPE WebKit Blog: WPE WebKit 2.44 highlights

Igalia WebKit

The WPE team released WPE WebKit 2.44 a few weeks ago. Let’s have a look at the most significant changes to the port for this release cycle.

DisplayLink is a WebCore feature that improves resource utilization and improves synchronization with vertical screen retrace. 2.44 adds an implementation of this feature for the WPE port that improves rendering performance.

Improved hardware-acceleration video decoding and rendering

When WebKit is using GStreamer 1.24 or newer, video playback can use the new support for DRM modifiers in the DMA-BUF sink. This improves video decoding and rendering, as it allows for zero-copy negotiation with the video decoders.

WebCodec API supported

WPE now supports the WebCodecs API, which allows web developers low-level access to video frames and audio chunks, a feature of importance for multimedia applications that need finer grain control over what gets played on the browser.

Other noteworthy changes

  • Support for the JPEG2000 image format has been removed. WebKit was the only major engine still supporting the format, which these days is rarely used. As a consequence, OpenJPEG is no longer a dependency. JPEG2000 should not be confused with JPEG-XL, which is still supported.
  • Support usage of libbacktrace, enabled by default at build time. This library provides quality stacktraces that can help developers and deployers more efficiently debug crashes in WPE-powered browsers.
  • Many memory and stability improvements, particularly on the multimedia backends.

For a complete list of changes, please check the releases page.

April 18, 2024 11:00 PM

April 16, 2024

Philippe Normand: From WebKit/GStreamer to rust-av, a journey on our stack’s layers

Igalia WebKit

In this post I’ll try to document the journey starting from a WebKit issue and ending up improving third-party projects that WebKitGTK and WPEWebKit depend on.

I’ve been working on WebKit’s GStreamer backends for a while. Usually some new feature needed on WebKit side would trigger work …

By Philippe Normand at April 16, 2024 08:15 PM

April 10, 2024

Release Notes for Safari Technology Preview 192

Surfin’ Safari

Safari Technology Preview Release 192 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.

This release includes WebKit changes between: 276247@main…276863@main.

Authentication

Resolved Issues

  • Fixed setting the cancel flag once the cancel completes regardless of a subsequent request occurring. (276368@main) (124727713)

CSS

New Features

  • Added support for View Transitions. (276426@main) (123128491)

Resolved Issues

  • Fixed setting white-space to a non-default value dynamically on a whitespace or a new line. (276277@main) (92559818)
  • Fixed the proximity calculation for implicit @scope. (276345@main) (124640124)
  • Fixed the Grid track sizing algorithm logical height computation avoid unnecessary grid item updates. (276633@main) (124713418)
  • Fixed any @scope limit making the element out of scope. (276359@main) (124956673)
  • Fixed the contrast of Menu and MenuText system colors. (276597@main) (125270664)
  • Fixed keeping the shorthand value for CSS gap as-is in serialized and computed values. (276794@main) (125335787)

Deprecations

  • Removed WEBKIT_KEYFRAMES_RULE and WEBKIT_KEYFRAME_RULE in CSSRule. (276264@main) (97084520)
  • Removed the SVGAnimateColorElement interface. (276683@main) (122586568)

Editing

Resolved Issues

  • Fixed certain text being duplicated or misplaced. (276317@main) (123642870)
  • Fixed word completion suggestion interfering with a website’s suggestion results. (276344@main) (124727588)

JavaScript

Resolved Issues

  • Fixed Object.groupBy and Map.groupBy to work for non-objects. (276736@main) (125485685)
  • Fixed Array.fromAsync to not call the Array constructor twice. (276752@main) (125509304)

Media

New Features

  • Added support for MSE in workers. (276389@main) (123052315)

Resolved Issues

  • Fixed scrolling for an element when a video element with pointer-events: none is placed over it. (276807@main) (118936715)
  • Fixed allowing a video’s currentTime to be further than the gap’s start time. (276761@main) (124186726)
  • Fixed sampleRate and numberOfChanges to be required and non-zero in a valid AudioEncoderConfig. (276413@main) (125107934)
  • Fixed media elements appending the same media segment twice. (276821@main) (125386530)

Rendering

Resolved Issues

  • Fixed adjusting the size of the scrollable area when changing betwen non-overlay and overlay scrollbars. (276439@main) (117507268)
  • Fixed flickering when showing a layer on a painted background for the first time by avoiding async image decoding. (276513@main) (117533495)
  • Fixed line breaking before or between ruby sequences. (276353@main) (122663646)

Web API

New Features

  • Added support for URL.parse(). (276656@main) (125376520)
  • Added support for shadowRootDelegatesFocus and shadowRootClonable to <template>. (276631@main) (125401993)

Resolved Issues

  • Fixed URL text fragment directives not fully stripped from JavaScript. (276370@main) (107326333)
  • Fixed inserting a <picture> element displaying the same image twice. (276754@main) (123795045)

Web Extensions

New Features

  • Updated to use the web extension architecture in open-source WebKit code. Web extension authors are encouraged to test your extensions and report issues. (123908710)

Web Inspector

Resolved Issues

  • Fixed console clearing unexpectedly when Web Inspector reopens. (276705@main) (124171190)

April 10, 2024 09:30 PM

Optimizing WebKit & Safari for Speedometer 3.0

Surfin’ Safari

The introduction of Speedometer 3.0 is a major step forward in making the web faster for all, and allowing Web developers to make websites and web apps that were not previously possible. In this article, we explore ways the WebKit team made performance optimizations in WebKit and Safari based on the Speedometer 3.0 benchmark.

In order to make these improvements, we made an extensive use of our performance testing infrastructure. It’s integrated with our continuous integration, and provides the capability to schedule A/B tests. This allows engineers to quickly test out performance optimizations and catch new performance regressions.

Improving Tools

Proper tooling support is the key to identifying and addressing performance bottlenecks. We defined new internal JSON format for JavaScriptCore sampling profiler output to dump and process them offline. It includes a script which processes and generates analysis of hot functions and hot byte codes for JavaScriptCore. We also added FlameGraph generation tool for the dumped sampling profiler output which visualizes performance bottlenecks. In addition, we added support for JITDump generation on Darwin platforms to dump JIT related information during execution. And we improved generated JITDump information for easy use as well. These tooling improvements allowed us to quickly identify bottlenecks across Speedometer 3.0.

Improving JavaScriptCore

Revising Megamorphic Inline Cache (IC)

Megamorphic IC offers faster property access when one property access site observes many different object types and/or property names. We observed that some frameworks such as React contain a megamorphic property access. This led us to continuously improve JavaScriptCore’s megamorphic property access optimizations: expanding put megamorphic IC, adding megamorphic IC for the in operation, and adding generic improvements for megamorphic IC.

Revising Call IC

Call IC offers faster function calls by caching call targets inline. We redesigned Call IC and we integrated two different architectures into different tiers of Just-In-Time (JIT) compilers. Lower level tiers use Call IC without any JIT code generation and the highest level tier uses JIT code generatiton with the fastest Call IC. There is a tradeoff between code generation time and code efficiency, and JavaScriptCore performs a balancing act between them to achieve the best performance across different tiers.

Optimizing JSON

Speedometer 3.0 also presented new optimization opportunities to our JSON implementations as they contain more non-ASCII characters than before. We made our fast JSON stringifier work for unicode characters. We also analyzed profile data carefully and made JSON.parse faster than ever.

Adjusting Inlining Heuristics

There are many tradeoffs when inlining functions in JavaScript. For example, inline functions can more aggressively increase the total bytecode size and may cause memory bandwidth to become a new bottleneck. The amount of instruction cache available in CPU can also influence how effective a given inlining strategy is. And the calculus of these tradeoffs change over time as we make more improvements to JavaScriptCore such as adding new bytecode instruction and changes to DFG’s numerous optimization phases. We took the release of the new Speedometer 3.0 benchmark as an opportunity to adjust inlining heuristics based on data collected in modern Apple silicon Macs with the latest JavaScriptCore.

Make JIT Code Destruction Lazy

Due to complicated conditions, JavaScriptCore eagerly destroyed CodeBlock and JIT code when GC detects they are dead. Since these destructions are costly, they should be delayed and processed while the browser is idle. We made changes so that they are now destroyed lazily, during idle time in most cases.

Opportunistic Sweeping and Garbage Collection

In addition, we noticed that a significant amount of time goes into performing garbage collection and incremental sweeping across all subtests in both Speedometer 2.1 and 3.0. In particular, if a subtest allocated a large number of JavaScript objects on the heap, we would often spend a significant amount of time in subsequent subtests collecting these objects. This had several effects:

  1. Increasing synchronous time intervals on many subtests due to on-demand sweeping and garbage collection when hitting heap size limits.
  2. Increasing asynchronous time intervals on many subtests due to asynchronous garbage collection or timer-based incremental sweeping triggering immediately after the synchronous timing interval.
  3. Increasing overall variance depending on whether timer-based incremental sweeping and garbage collection would fall in the synchronous or asynchronous timing windows of any given subtest.

At a high level, we realized that some of this work could be performed opportunistically in between rendering updates — that is, during idle time — instead of triggering in the middle of subtests. To achieve this, we introduced a new mechanism in WebCore to provide hints to JavaScriptCore to opportunistically perform scheduled work after the previous rendering update has completed until a given deadline (determined by the estimated remaining time until the next rendering update). The opportunistic task scheduler also accounts for imminently scheduled zero delay timers or pending requestAnimationFrame callbacks: if it observes either, it’s less likely to schedule opportunistic work in order to avoid interference with imminent script execution. We currently perform a couple types of opportunistically scheduled tasks:

  • Incremental Sweeping: Prior to the opportunistic task scheduler, incremental sweeping in JavaScriptCore was automatically triggered by a periodically scheduled 100 ms timer. This had the effect of occasionally triggering incremental sweeping during asynchronous timing intervals, but also wasn’t aggressive enough to prevent on-demand sweeping in the middle of script execution. Now that JavaScriptCore is knowledgable about when to opportunistically schedule tasks, it can instead perform the majority of incremental sweeping in between rendering updates while there aren’t imminently scheduled timers. The process of sweeping is also granular to each marked block, which allows us to halt opportunistic sweeping early if we’re about to exceed the deadline for the next estimated rendering update.
  • Garbage Collection: By tracking the amount of time spent performing garbage collection in previous cycles, we’re able to roughly estimate the amount of time needed to perform the next garbage collection based on the number of bytes visited or allocated since the last cycle. If the remaining duration for performing opportunistically scheduled tasks is longer than this estimated garbage collection duration, we immediately perform either an Eden collection or full garbage collection. Furthermore, we integrated activity-based garbage collections into this new scheme to schedule them at appropriate timing.

Overall, this strategy yields a 6.5% total improvement in Speedometer 3.0*, decreasing the time spent in every subtest by a significant margin, and a 6.9% total improvement in Speedometer 2.1*, significantly decreasing the time spent in nearly all subtests.

* macOS 14.4, MacBook Air (M2, 2022)

Various Miscellaneous Optimizations for Real World Use Cases

We extensively reviewed all Speedometer 3.0 subtests and did many optimizations for realistic use cases. The examples include but are not limited to: faster Object.assign with empty objects, improving object spread performance, and so on.

Improving DOM code

Improving DOM code is Speedometer’s namesake, and that’s exactly what we did. For example, we now store the NodeType in the Node object itself instead of relying on a virtual function call. We also made DOMParser use a fast parser, improved its support of li elements, and made DOMParser not construct a redundant DocumentFragment. Together, these changes improved TodoMVC-JavaScript-ES5 by ~20%. We also eliminated O(n^2) behavior in the fast parser for about ~0.5% overall progression in Speedometer 3.0. We also made input elements construct their user-agent shadow tree lazily during construction and cloning, the latter of which is new in Speedometer 3.0 due to web components and Lit tests. We devirtualized many functions and inlined more functions to reduce the function call overheads. We carefully reviewed performance profile data and removed inefficiency in hot paths like repeated reparsing of the same URLs.

Improving Layout and Rendering

We landed a number of important optimizations in our layout and rendering code. First off, most type checks performed on RenderObject are now done using an inline enum class instead of virtual function calls, this alone is responsible for around ~0.7% of overall progression in Speedometer 3.0.

Improving Style Engine

We also optimized the way we compute the properties animated by Web Animations code. Previously, we were enumerating every animatable properties while resolving transition: all. We optimized this code to only enumerate affected properties. This was ~0.7% overall Speedometer 3.0 progression. Animating elements can now be resolved without fully recomputing their style unless necessary for correctness.

Speedometer 3.0 content, like many modern web sites, uses CSS custom properties extensively. We implemented significant optimizations to improve their performance. Most custom property references are now resolved via fast cache lookups, avoiding expensive style resolution time property parsing. Custom properties are now stored in a new hierarchical data structure that reduces memory usage as well.

One key component of WebKit styling performance is a cache (called “matched declarations cache”) that maps directly from a set of CSS declarations to the final element style, avoiding repeating expensive style building steps for identically styled elements. We significantly improved the hit rate of this cache.

We also improved styling performance of author shadow trees, allowing trees with identical styles to share style data more effectively.

Improving Inline Layout

We fixed a number of performance bottlenecks in inline layout engine as well. Eliminating complex text path in Editor-TipTap was a major ~7% overall improvement. To understand this optimization, WebKit has two different code paths for text layout: the simple text path, which uses low level font API to access raw font data, and the complex text path, which uses CoreText for complex shaping and ligatures. The simple text path is faster but it does not cover all the edge cases. The complex text path has full coverage but is slower than the simple text path.

Previously, we were taking the complex text path whenever a non-default value of font-feature or font-variant was used. This is because historically the simple text path wouldn’t support these operations. However, we noticed that the only feature of these still missing in the simple text path was font-variant-caps. By implementing font-variant-caps support for the simple text path, we allowed the simple text path to handle the benchmark content. This resulted in 4.5x improvement in Editor-TipTap subtest, and ~7% overall progression in Speedometer 3.0.

In addition to improving the handling of text content in WebKit, we also worked with CoreText team to avoid unnecessary work in laying out glyphs. This resulted in ~0.5% overall progression in Speedometer 3.0, and these performance gains will benefit not just WebKit but other frameworks and applications that use CoreText.

Improving SVG Layout

Another area we landed many optimizations for is SVG. Speedometer 3.0 contains a fair bit of SVG content in test cases such as React-Stockcharts-SVG. We were spending a lot of time computing the bounding box for repaint by creating GraphicsContext, applying all styles, and actually drawing strokes in CoreGraphics. Here, we adopted Blink’s optimization to approximate bounding box and made ~6% improvement in React-Stockcharts-SVG subtest. We also eliminated O(n^2) algorithm in SVG text layout code, which made some SVG content load a lot quicker.

Improving IOSurface Cache Hit Rate

Another optimization we did involve improving the cache hit rate of IOSurface. An IOSurface is a bitmap image buffer we use to paint web contents into. Since creating this object is rather expensive, we have a cache of IOSurface objects based on their dimensions. We observed that the cache hit rate was rather low (~30%) so we increased the cache size from 64MB to 256MB on macOS and improved the cache hit rate by 2.7x to ~80%, improving the overall Speedometer 3.0 score by ~0.7%. In practice, this means lower latency for canvas operations and other painting operations.

Reducing Wait Time for GPU Process

Previously, we required a synchronous IPC call from the Web Process to the GPU process to determine which of the existing buffers had been released by CoreAnimation and was suitable to use for the next frame. We optimized this by having the GPUP just select (or allocate) an appropriate buffer, and direct all incoming drawing commands to the right destination without requiring any response. We also changed the delivery of any newly allocated IOSurface handles to go via a background helper thread, rather than blocking the Web Process’s main thread.

Improving Compositing

Updates to compositing layers are now batched, and flushed during rendering updates, rather than computed during every layout. This significantly reduces the cost of script-incurred layout flushes.

Improving Safari

In addition to optimizations we made in WebKit, there were a handful of optimizations for Safari as well.

Optimizing AutoFill Code

One area we looked at was Safari’s AutoFill code. Safari uses JavaScript to implement its AutoFill logic, and this execution time was showing up in the Speedometer 3.0 profile. We made this code significantly faster by waiting for the contents of the page to settle before performing some work for AutoFill. This includes coalescing handling of newly focused fields until after the page had finished loading when possible, and moving lower-priority work out of the critical path of loading and presenting the page for long-loading pages. This was responsible for ~13% progression in TodoMVC-React-Complex-DOM and ~1% progression in numerous other tests, improving the overall Speedometer 3.0 score by ~0.9%.

Profile Guided Optimizations

In addition to making the above code changes, we also adjusted our profile-guided optimizations to take Speedometer 3.0 into account. This allowed us to improve the overall Speedometer 3.0 score by 1~1.6%. It’s worth noting that we observed an intricate interaction between making code changes and profile-guided optimizations. We sometimes don’t observe an immediate improvement in the overall Speedometer 3.0 score when we eliminate, or reduce the runtime cost of a particular code path until the daily update of profile-guided optimizations kicks. This is because the modified or newly added code has to benefit from profile-guided optimizations before it can show a measurable difference. In some cases, we even observed that a performance optimization initially results in a performance degradation until the profile-guided optimizations are updated.

Results

With all these optimizations and dozens more, we were able to improve the overall Speedometer 3.0 score by ~60% between Safari 17.0 and Safari 17.4. Even though individual progressions were often less than 1%, over time, they all stacked up together to make a big difference. Because some of these optimizations also benefited Speedometer 2.1, Safari 17.4 is also ~13% faster than Safari 17.0 on Speedometer 2.1. We’re thrilled to deliver these performance improvements to our users allowing web developers to build websites and web apps that are more responsive and snappier than ever.

April 10, 2024 05:00 PM

March 28, 2024

Release Notes for Safari Technology Preview 191

Surfin’ Safari

Safari Technology Preview Release 191 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.

This release includes WebKit changes between: 274942@main…276246@main.

Accessibility

New Features

  • Added support for ariaBrailleLabel and ariaBrailleRoleDescription element reflection properties. (275591@main) (123926949)

Resolved Issues

  • Fixed a bug preventing VoiceOver word echoing in some text fields. (275694@main) (122451549) (FB13592798)
  • Fixed time input accessibility by adding labels to subfields. (275301@main) (122590568)
  • Fixed datetime values being exposed to assistive technologies in the wrong timezone. (275265@main) (123522296)
  • Fixed time control accessibility by adding a label to the meridiem component. (276195@main) (123781149)
  • Fixed wrong datetime value being exposed to assistive technologies for datetime-local inputs. (275548@main) (123803281)
  • Fixed the computed role for these elements: dd, details, dt, em, hgroup, option, s, and strong. (276240@main) (124641956)

Authentication

Resolved Issues

  • Fixed excludeCredentials property being ignored during a passkey registration request. (276006@main) (124405037)

CSS

Resolved Issues

  • Fixed getComputedStyle() to work with functional pseudo-elements like ::highlight(). (274846@main) (117864743)
  • Fixed changing color scheme to update gradients with system colors or light-dark(). (275645@main) (121285450)
  • Fixed :empty selector to work with animations. (275832@main) (122838142)
  • Fixed starting style to inherit from its parent’s after-change style. (275061@main) (123302667)
  • Fixed CSS container style queries to allow !important. (275104@main) (123374708)
  • Fixed preserving whitespace when serializing custom properties. (275236@main) (123491915)
  • Fixed updating style correctly for non-inherited custom property mutations. (275445@main) (123645196)
  • Fixed element removed by parent to end up losing the last remembered size. (275606@main) (123975513)
  • Fixed resolving container units in style queries. (275689@main) (124058441)

Forms

Resolved Issues

  • Fixed native text fields becoming invisible in dark mode. (275363@main) (123658326)
  • Fixed <select multiple> scrollbars to match the used color scheme. (275505@main) (123807167)
  • Fixed fallback native <select> rendering in dark mode. (275532@main) (123845293)

JavaScript

Resolved Issues

  • Fixed String.prototype.replace to not take the fast path if the pattern is RegExp Object and the lastIndex is not numeric. (275255@main) (101122567)
  • Fixed Symbol.species getters to not share a single JS Function. (275064@main) (120416817)
  • Fixed try/catch to not intercept errors originated in [[Construct]] of derived class. (275353@main) (121959506)
  • Fixed TypedArray sorting methods to have a special-case for camparator returning false. (276130@main) (122093956)
  • Fixed emitReturn() to load this value from arrow function lexical environment prior to the TDZ check. (275425@main) (122430056)
  • Fixed NFKC normalization to work with Latin-1 characters. (275062@main) (123328161)
  • Fixed parsing of private names with Unicode start characters. (275152@main) (123425805)
  • Fixed instanceof to not get RHS prototype when LHS is primitive. (275318@main) (123629166)
  • Fixed bracket update expression to resolve property key at most once. (275531@main) (123872374)
  • Fixed bracket compound assignement to resolve the property key at most once. (276014@main) (124420301)

Lockdown Mode

Resolved Issues

  • Fixed: Updated the trusted list of fonts to address missing glyphs on some sites. (275705@main) (123658932)

Media

New Features

  • Added support for WebCodecs AV1 when an AV1 hardware decoder is available. (275174@main) (123433815)

Resolved Issues

  • Fixed audio distortion over internal speakers when streaming content in web browsers. (275262@main) (122590884)
  • Fixed playback for MSE videos on some sites. (275443@main) (123528095)
  • Fixed firing loadeddata events for <audio> and <video> on page load. (275997@main) (124079735) (FB13675360)

SVG

Resolved Issues

  • Fixed returning the initial value for the SVG gradient stop-color if it is not rendered in the page. (274997@main) (123262508)
  • Fixed the SVG marker segment calculations if the marker path consists of sub-paths. (275167@main) (123434203)

Web API

Resolved Issues

  • Fixed cssTextsetter to change the style attribute when the serialization differs. (276176@main) (29861252) (FB5535475)
  • Fixed mousemove events in an iframe when the mouse is clicked from outside the iframe and then moves into it while the button is held down. (275157@main) (120540148) (FB13517196)
  • Fixed getGamepads() to no longer trigger an insecure contexts warning. (274962@main) (123039555)

Deprecations

  • Removed HashChangeEvent‘s non-standard initHashChangeEvent() method. (276232@main) (124736521)

Web Inspector

Resolved Issues

  • Fixed expanded sections of Storage to not collapse. (275783@main) (107687975)
  • Fixed CSS font property values marked !important not getting overridden when using the interactive editing controls. (275389@main) (112080113)
  • Fixed runtimes to be aligned in the Audit tab. (275298@main) (121810292)
  • Fixed info and debug buttons not appearing in the Console Tab until new console messages are displayed. (275914@main) (122923625)
  • Fixed remembering the message type selection in the Console tab. (275143@main) (122924275)
  • Fixed autocomplete for the text-indent property suggesting prefixed properties instead of each-line or hanging. (274979@main) (123240715)
  • Fixed background autocompletion suggestion to include repeating-conic-gradient. (275160@main) (123428709)

WebRTC

Resolved Issues

March 28, 2024 02:16 PM

March 20, 2024

Jani Hautakangas: Bringing WebKit back to Android.

Igalia WebKit

It’s been quite a while since the last blog post about WPE-Android, but that doesn’t mean WPE-Android hasn’t been in development. The focus has been on stabilizing the runtime and implementing the most crucial core features to make it easier to integrate new APIs into WPEView.

Main building blocks #

WPE-Android has three main building blocks:

  • Cerbero
    • Cross-platform build aggregator that is used to build WPE WebKit and all of its dependencies to Android.
  • WPEBackend-Android
    • Implements Android specific graphics buffer support and buffer sharing between WebKit UIProcess and WebProcess.
  • WPEView
    • Allows displaying web content in activity layout using WPEWebKit.

WPE-Android high-level design

What’s new #

The list of all work completed so far would be quite long, as there have been no official releases or public announcements, with the exception of the last blog post. Since that update, most of the efforts have been focused on ‘under the hood’ improvements, including enhancing stability, adding support for some core WebKit features, and making general improvements to the development infrastructure.

Here is a list of new features worth mentioning:

  • Based on WPE WebKit 2.42.1, the project was branched for the 2.42.x series. Future work will continue in the main branch for the next release.
  • Dropped support for 32-bit platforms (x86 and armv7). Only arm64-v8a and x86_64 are supported
  • Integration to Android main loop so that WPE WebKit GLib main loop is driven by Android main loop
  • Process-Swap On Navigation aka PSON
  • Added ASharedMemory support to WebKit SharedMemory
  • Hardware-accelerated multimedia playback
  • Fullscreen support
  • Cookies management
  • ANGLE based WebGL
  • Cross process fence insertion for composition synchronization with Surface Flinger
  • WebDriver support
  • GitHub Actions build bots
  • GitHub Actions WebDriver test bots

Demos #

WPEWebkit powered web view (WPEView) #

Demo uses WPE-Android MiniBrowser sample application to show basic web page loading and touch-based scrolling, usage of a simple cookie manager to clear the page’s date usage, and finally loads the popular “Aquarium sample” to show a smooth (60FPS) WebGL animation running thanks to HW acceleration support.

WebDriver #

Demo shows how to run WebDriver test with with emulator. Detailed instructions how to run WebDriver test can be found in README.md

Test requests a website through the Selenium remote webdriver. It then replaces the default behavior of window.alert on the requested page by injecting and executing a JavaScript snippet. After loading the page, it performs a click() action on the element that calls the alert. This results in the text ‘cheese’ being displayed right below the ‘click me’ link.

Test contains three building blocks:

  • WPE WebDriver running on emulator
  • HTTP server serving test.html web page
  • Selenium python test script executing the test

What’s next #

We have ambitious plans for the coming months regarding the development of WPE Android, focusing mainly on implementing additional features, stabilization, and performance improvements.

As for implementing new features, now that the integration with the WPE WebKit runtime has reached a more robust state, it’s time to start adding more of the APIs that are still missing in WPEView compared to other webviews on Android and to enable other web-facing features supported by WebKit. This effort, along with adding support for features like HTTP/2 and the remote Web Inspector, will be a major focus.

As for stabilization and performance, having WebDriver support will be very helpful as it will enable us to identify and fix issues promptly and thus help make WPE Android more stable and feature-complete. We would also like to focus on conformance testing compared to other web views on Android, which should help us prioritize our efforts.

The broader goal for this year is to develop WPE-Android into an easy-to-use platform for third-party projects, offering a compelling alternative to other webviews on the Android platform. We extend many thanks to the NLNet Foundation, whose support for WPE Android through a grant from the NGI Zero Core fund will be instrumental in helping us achieve this goal!

Try it yourself #

WPE-Android is still considered a prototype, and it’s a bit difficult to build. However, if you want to try it out, you can follow the instructions in the README.md file. Additionally, you can use the project’s issue tracker to report problems or suggest new features.

March 20, 2024 12:00 AM

March 19, 2024

Introducing Natural Input for WebXR in Apple Vision Pro

Surfin’ Safari

Apple Vision Pro is here, and with it, a lot of excitement about the possibilities for WebXR in visionOS. Support is in progress, where you can test it today.

WebXR now includes a more natural and privacy-preserving method for interaction — the new transient-pointer input mode — available for Safari 17.4 in visionOS 1.1. Let’s explore how natural input for WebXR works, and how to leverage it when developing a WebXR experience for Apple Vision Pro.

Background

WebXR lets you transform 3D experiences created in WebGL into immersive, spatial experiences available directly in the browser. Defined in web standards governed by the W3C, WebXR is an excellent choice for presenting immersive content to your users.

One challenge, though, is that because it’s completely immersive — and rendered entirely through WebGL — it’s not possible to provide interaction via DOM content or the traditional two-dimensional input available on a typical web page via a mouse or trackpad. This, combined with the fact that a spatial experience requires spatial input, means WebXR needs a totally new interaction model.

The interaction model of visionOS, known as natural input, uses a combination of eyes and hands for input. A user simply looks at a target and taps their fingers to interact. (Or uses the alternatives provided by accessibility features.)

The initial web standards for WebXR assumed all input would be provided by persistent hardware controllers. Since the natural input interaction model of visionOS differs from XR platforms which rely on listening to physical controllers and button presses, many existing WebXR experiences won’t work as intended on Apple Vision Pro.

We’ve been collaborating in the W3C to incorporate support for the interaction model of visionOS into WebXR. And we’re excited to help the WebXR community add support to popular WebXR frameworks.

Using Natural Input interactions

Since WebXR in visionOS requires the use of spatial inputs, rather than a trackpad, touch, or mouse, and the DOM isn’t visible within a WebXR session, inputs are provided as part of the XRSession itself. Events related to the input, e.g. select, selectstart and selectend are then dispatched from the session object. The XRInputSources are available within the xrSession.inputSources array. Because the default WebXR input in visionOS is transient, that array is empty — until the user pinches. At that moment, a new input is added to the array, and the session fires an inputsourceschange event followed by a selectstart event. You can use these for detecting the start of the gesture. To differentiate this new input type, it has a targetRayMode of transient-pointer.

Ongoing interaction

The XRInputSource contains references to two different positions in space related to the input: the targetRaySpace and the gripSpace. targetRaySpace represents the user’s gaze direction, this space begins with its origin between the user’s eyes and points to what the user was looking at the start of the gesture. The targetRaySpace is initially set to the direction of the user’s gaze but is updated with the movement of their hand rather than their eyes — that is, a movement of the hand to the left will move that ray to the left as well. The gripSpace represents the location of the user’s pinching fingers at the current point in time.

The targetRaySpace can be used for finding what the user wanted to interact with when they started the gesture typically by raycasting into the scene and picking the intersected object and the gripSpace can be used for the positioning and orientation of objects near the user’s hand for interaction purposes, e.g. to flip a switch, turn a dial or pick up an item from the virtual environment. To learn more about finding the pose of the input, see Inputs and input sources on MDN.

End of interaction

Three events are fired from the session object when the user releases the pinch.

First is a select and selectEnd event, both referencing the input as the event.inputSource object. The session then fires a final inputsourceschange event, indicating that this inputSource has been removed.

Benefits for simplicity and privacy

As each input represents a single, tracked point in space per pinch, and because it exists only for the duration of the user’s pinch, significantly less data about a user’s motion is required overall.

Combining transient inputs with hand tracking

WebXR on Safari in visionOS continues to support full hand tracking as well, supplying hand joint information for the duration of the experience. If the call to navigator.xr.requestSession has included hand-tracking as an additional feature and this is granted by the user, the first two inputs in the inputSources list will be standard tracked-pointers supplying this joint information. For information on requesting features in an XRSession, refer to the documentation at MDN. Because these inputs persist for the duration of the session, any transient-pointer inputs will appear further down the list. The hand inputs are supplied for pose information only and do not trigger any events.

Testing natural input on visionOS

Using the visionOS simulator

The new transient-pointer input mode works in the visionOS simulator, so you can test your Web XR experience without needing Apple Vision Pro. To get started:

  1. Download Xcode from the Mac App Store.
  2. Select the visionOS SDK for download and installation.
    Checklist of which platforms you would like to develop for — macOS and visionOS are checked, ready to press the download & install button.
  3. Launch Xcode to complete the installation process. This installs a new application named “Simulator”. Learn more about using the visionOS Simulator.
  4. Open the Simulator app on macOS.
  5. Create a new visionOS simulator or open an existing one.

If you have a website open in Safari on macOS, you can easily trigger that page to open in Safari in visionOS Simulator. On Mac, select Develop > Open Page With > Apple Vision Pro. (If the Develop menu is not present in the menu bar, enable features for web developers.)

Enabling WebXR support

Whether you have Apple Vision Pro or are using visionOS Simulator, you’ll want to turn on support for WebXR. From the Home View, go to Settings > Apps > Safari > Advanced > Feature Flags and enable WebXR Device API.

Identifying potential issues in existing WebXR scenes

WebXR is provided in visionOS 1.1 for testing purposes only. If you encounter bugs in the browser, please don’t attempt to target a user-agent string to work around them. Instead, report them to us via Feedback Assistant.

When hand-tracking is enabled I can’t select anything.

Your experience probably is only looking at events which correspond to the first two inputs in the inputSources array. Many examples in the popular framework Three.js only act on events related to inputs at index 0 and 1. When hand tracking is enabled, the inputs corresponding to the hand tracking data appear in entries 0 and 1 but the transient-pointer style inputs appear in entries 2 and 3.

When I attach an object to the controller it appears at the user’s face.

The input’s targetRaySpace originates between the user’s eyes and points in the direction of their gaze. To place an object in the user’s hand, instead attach objects to the input’s gripSpace position, which corresponds to the location of the user’s pinch.

The selection ray to interact with objects lags between the position of my current selection and my last one.

Some frameworks attempt to smooth out controller motion by interpolating the position of the controller each frame. This interpolated motion should be reset if a controller is disconnected and reconnected. You may need to file an issue with the framework author.

Let us know

We can’t wait to see what you make. To share your thoughts on WebXR, find us on Mastodon at @ada@mastodon.social, @jensimmons@front-end.social, @jondavis@mastodon.social, or on X at @zachernuk. Or send a reply on X to @webkit. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your feedback (to include a sysdiagnose from Apple Vision Pro), or your WebKit bug report about Web Inspector or web platform features. Filing issues really does make a difference. Thanks.

March 19, 2024 04:30 PM

March 18, 2024

Implementing Vertical Form Controls

Surfin’ Safari

Safari 17.4 adds vertical writing mode support for form control elements across macOS, iOS, iPadOS, and visionOS.

all the form controls, typeset vertically

Setting written text vertically is commonly observed in East Asian languages. For example, Chinese, Japanese, and Korean (CJK) may be written vertically and read top-to-bottom, flowing in lines from right to left. Similarly, Traditional Mongolian is a vertical script that flows in lines from left to right.

Support for vertical text has been available in browsers for several years using the CSS writing-mode property. However, until recently, support for the vertical-lr and vertical-rl values for form controls was inconsistent among all browsers. Consequently, as part of Interop 2023, the industry committed to working towards vertical writing mode support in form controls. We are excited to see cross-browser support improve considerably. And we are proud that Safari 17.4 brings support for vertical writing modes to form controls everywhere you find Safari.

Using vertical writing modes with form controls

Adopting vertical form controls is as simple as adding a CSS declaration using the writing-mode property and applying it to your controls. For a right-to-left block flow direction, as observed in CJK languages, use writing-mode: vertical-rl. Or, for a left-to-right block flow direction, use writing-mode: vertical-lr.

button, textarea, progress, meter, input, select {
    writing-mode: vertical-rl;
}

Support for vertical writing mode is available for the following elements: <button>, <textarea>, <progress>, <meter>, <input>, and <select>. WebKit is committed to supporting vertical writing modes on any new controls moving forward, including <input type="checkbox" switch>, which was also added in Safari 17.4.

Note that in all browsers, any popup UIs associated with form controls, such as the menu for a <select> element, or the color picker for an <input type="color"> are still displayed horizontally.

Implementation

Adding vertical writing mode support for form control elements in WebKit was a large undertaking that involved over 10 unique types of controls. Below are some of the changes that were needed to support this feature in WebKit.

Style

WebKit’s user-agent stylesheet made frequent use of physical properties, such as width, height, and margin. In order to support vertical writing modes, this usage was updated to use logical properties, such as inline-size and block-size, where appropriate.

Layout

Form controls in WebKit make heavy use of custom layout code. While the interfaces were designed to support logical properties, the implementations often assumed a horizontal writing mode. We updated the methods to compute logical widths to ensure they considered the writing mode.

Additionally, custom baseline adjustment logic, which makes controls such as checkboxes and radio buttons look great alongside text, was updated to use the central baseline for vertical writing modes. This ensures that controls continue to look great alongside text in a vertical writing mode.

Rendering

Rendering form controls with a vertical writing mode required unique changes depending on the control and system capabilities.

On macOS, WebKit’s form controls match the look and feel of the operating system. However, macOS itself does not support vertical writing modes. Consequently, some controls, such as <progress>, are simply rotated after obtaining the system image in order to support vertical rendering.

two progress bars, laid out horizontally and vertically

Other controls cannot simply be rotated due to details such as shadows, for example <select>, so we used a custom fallback rendering approach.

the select menu typeset vertically

If a control was already custom painted in WebKit, it was updated to use logical coordinates rather than physical coordinates. We used this approach throughout the iOS rendering code and it was also necessary in our rewrite of the listbox (<select multiple>) on macOS.

the select multiple form control, typeset vertically

Finally, some controls, such as checkbox and radio buttons, did not require any rendering changes. As “glyph-like” controls, they look the same in all writing modes.

checkboxes and radio buttons on iOS typeset vertically

WebKit remains committed to improving internationalization support in our engine. By adding vertical writing mode support for form control elements in Safari 17.4, we hope to empower authors to create the best content for their local and global communities.

A special thanks goes to Tim Nguyen, who kicked off the vertical form controls project in WebKit, and Alan Baradlay, whose deep knowledge of CSS layout proved invaluable in driving the project to the finish line.

Feedback

We love hearing from you. Send a tweet to @webkit to share your thoughts on this feature. Find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your WebKit bug reports on WebKit features like this. Reporting issues makes an enormous difference.

You can also download the latest Safari Technology Preview to try out new web platform features like this before they appear in a Safari beta.

March 18, 2024 03:00 PM

March 11, 2024

Speedometer 3.0: The Best Way Yet to Measure Browser Performance

Surfin’ Safari

As announced on browserbench.org today, in collaboration with other browser engine developers, Apple’s WebKit team is excited to introduce Speedometer 3.0, a major update that better reflects the Web of today. It’s built together by the developers of all major browser engines: Blink, Gecko, and WebKit with hundreds of contributions from companies like Apple, Google, Intel, Microsoft, and Mozilla. This post is a deep dive into how the collaborative Speedometer project improved the benchmark’s measurements methods and test content.

To recap history, in 2014, the WebKit team at Apple released the Speedometer browser benchmark, designed to measure the responsiveness of websites and web apps.

The original Speedometer simulated user interactions in web applications, driving TodoMVC sample apps written using different JavaScript frameworks to add, complete, and remove todo items. It was unlike other DOM or web app benchmarks publicly available at the time. These older benchmarks were mostly collections of micro-benchmarks, and didn’t reflect how DOM APIs were used in real web apps, or how individual APIs interacted with the rest of the web browser engine. Speedometer quickly became an important tool for performance measurement and tuning not just in WebKit but also in other browser engines.

In 2018 the WebKit team, in collaboration with Google’s Chrome team, released Speedometer 2.0, updated to use the latest frameworks and libraries available at the time. The Speedometer benchmark has since gained even more popularity among browser engines as a guide for optimization, and among independent testers and reviewers to compare different devices, operating systems, and browsers.

Today’s release of Speedometer 3.0 marks a major step forward in web browser performance testing. It improves the accuracy of measurement and measures the performance of a wide variety of contents.

Cross-Browser Collaboration

Speedometer 3.0’s release is a result of the collaboration among browser developers to improve the Web as a whole together. Much as Interop 2024 represents joint work to test and improve standards compliance, Speedometer 3.0 is a joint effort to test and improve browser performance.

Where previous Speedometer versions were developed as part of the WebKit project, Speedometer 3.0 has been developed and released under a joint multi-stakeholder governance model including the three major engine browsers: Blink, Gecko, and WebKit, and the repository has received hundreds of open source contributions since the original announcement in December 2022. This collaboration better ensures fairness in measurement and workload composition. And together, the group created a shared vision for the benchmark.

Improved Test Harness

We’ve improved the way Speedometer measures runtime performance. Prior Speedometer versions measured the time to run a test script synchronously as “sync” time; and the time until a zero-delay timer scheduled at the end of “sync” work fires as “async” time, as shown in the following diagram:

In Speedometer 2, async time was measured as between when a timer is scheduled at the end of sync time and when the timer fires. That sometimes captures layout and paint and other tasks running after synchronous script execution but before the timer fires.

However, this method sometimes misses important work that browser engines do in response to script-driven changes, because synchronous tasks and the zero-delay timer are scheduled without considering the timing of rendering updates. It also didn’t capture any work frameworks delay until the next requestAnimationFrame (rAF) callback, a common technique in modern frameworks. The following diagram illustrates how important work could be missed by the time calculations.

In Speedometer 2, it was possible that requestAnimationFrame, layout, and paint to happen after the async timer had fired in some cases. In such cases, we fail to capture the time browser spends updating the rendering of a web page.

Speedometer 3.0 takes advantage of the fact that all browser engines have adopted the HTML5 event loop model for updating the webpage rendering. It measures test scripts within a requestAnimationFrame callback as “sync” time, and the time to fire zero-delay timer scheduled in a second requestAnimationFrame as “async” time:

In Speedometer 3, we schedule two requestAnimationFrame callbacks. The first one runs and measures sync time, and the second one schedules a timer to measure the async time. Because browsers are expected to update the rendering after invoking requestAnimationFrame callback but before running any other tasks, we always capture the time browser spends updating the rendering of a web page.

Because the zero-delay timer is now scheduled in a second requestAnimationFrame, it’s guaranteed to be fired after all the zero-delay timers scheduled during the synchronous portion of the test had fired. Thanks to HTML5’s event loop processing model, browser engines update the rendering of web pages after all requestAnimationFrame are called before the next zero-delay timer fires. These changes greatly improved Speedometer’s ability to accurately measure the runtime of synchronous work and asynchronous work browsers do in response to script that handles user events.

The test harness has also been rewritten to use modern JavaScript features like modules, native promises, let & const, async & await, and class syntax, which were not widely available at the time Speedometer 1.0 was first written.

Like its precursors, Speedometer 3.0 sums up the runtime taken to simulate user actions such as adding todo items, completing them, and removing them per each workload, and computes the geometric mean of the totals across different workloads. The final score is calculated as the arithmetic mean of the reciprocal of the geometric mean:

In Speedometer 3, each workload can have multiple sync and async times. The total time for all sync and async time is calcualted for each workload, and the score is calculated as the reciprocal of the geometric mean of the totals across workloads.

Adjustment to Score

Since Speedometer’s benchmark content was last updated in 2018, web browsers have gotten increasingly better at handling Speedometer content. Moreover, new hardware, such as Apple Silicon Macs, continues to push the boundary of what’s possible in computing. Where originally scores were scaled to be under 100, modern browsers now can score over 500 on the fastest devices. To make scores easier to compare and to make room for future improvements, we’ve adjusted the score so that a typical web browser will get a score in the 20-30 range to start out.

Updated UI Frameworks

Now let’s take a look at the test content in Speedometer 3. Like the past versions of Speedometer, version 3.0 includes TodoMVC-based todo apps that emulate adding, completing, and removing todo items. To better represent the modern Web, the most widely used JavaScript UI frameworks were identified from the HTTP Archive in March 2023:

In the order of popularity, React, Vue.js, React, Backbone.js, AngularJS, Next.js, Angular, Nuxt.js, lit-html, Knockout.js, Alpine.js, Marionette.js, Gatsby, Svelte, React Redux

The monthly downloads in NPM was also taken into account to find frameworks with high momentum:

In the order of NPM monthly downloads, React, React Redux, Next.js, Vue.js, Angular, Preact, lit-html, Backbone.js, Nuxt.js, Svelte, AngularJS, Gatsby, Alpine.js, Knockout.js, Marionette.js

Based on these data points, we’ve included the following JavaScript frameworks in our todo apps: Angular, Backbone, jQuery, Lit, Preact, React, React+Redux, Svelte, and Vue. For each framework, the most commonly used version at the time was picked. Todo implementations written in vanilla JavaScript using ES5, ES6, and web components are also included.

Complex DOM Versions

In addition, Speedometer 3.0 includes “complex DOM” versions of some of the TodoMVC applications. In these complex DOM versions, each todo app is embedded inside a UI structure which mimics a web application with many deeply nested DOM nodes and plenty of CSS rules. Even though the benchmark still emulates the same set of operations, doing so in the context of more DOM elements and CSS rules adds work and captures additional performance bottlenecks.

In order to ensure the variety of performance scenarios to be tested, Speedometer 3.0 includes 6 simple DOM todo applications and 6 complex DOM todo applications.

Complex DOM workloads has ribbon menus, side bar tree view, search field, and other complex UI elements surrounding the todo app.

Broader Content

Together, these changes to todo apps dramatically improved the coverage of the benchmark. But Speedometer 3.0 takes it a step further and includes entirely new kinds of applications.

Speedometer 3.0 includes two test apps that mimic typical news sites, built using the popular single page application frameworks Next.js and Nuxt. It emulates user actions such as clicking on menu items and navigating to another page in the single page app setup.

News sites workload mimics a popular news site with navigation menu, hero images, headlines, and a summary of articles.

Speedometer 3.0 also includes four charting applications based on Observable Plot, chart.js, React stockcharts, and WebKit’s performance dashboards. Observable Plot and React Stockcharts are based on D3 and test manipulating SVG-based graphics. Chart.js and WebKit’s performance dashboards test drawing canvas-based graphics.

Charting workloads draw bar graphs of the number of airports in each U.S. state for example.

Finally, Speedometer 3.0 has added two text editing applications: a JavaScript code editor built with CodeMirror and a WYSIWYG editor built with TipTap. In both scenarios, it emulates the steps to create a new editable region, loading a large amount of text, and syntax highlighting or boldening text:

CodeMirror workload, for example, loads React's codebase and enables syntax highlighting

The addition of these new applications dramatically broadens the scope of what Speedometer 3.0 measures, and provide new opportunities for browser engines to optimize a broad spectrum of features like JavaScript, style, layout, graphics, and DOM.

Future Work

Today marks a remarkable milestone for the Web platform. Speedometer 3.0 sets a whole new standard for measuring web browser performance. As browser developers optimize their engines, this will expand the horizon of what Web developers can achieve in the years to come. Because the goal of the Speedometer benchmark is to reflect the real-world Web as much as possible, we’re expecting this benchmark to evolve over time. We’ll be regularly updating the list of frameworks to be tested, and periodically updating the tested framework’s versions to reflect the real world usage. You can
try Speedometer 3 benchmark on browserbench.org. If you have any feedback or questions, feel free to file issues on Github.

March 11, 2024 04:00 PM

March 06, 2024

Release Notes for Safari Technology Preview 190

Surfin’ Safari

Safari Technology Preview Release 190 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.

This release includes WebKit changes between: 274067@main…274941@main.

Authentication

New Features

  • Added support for CTAP to set a pin. (274385@main) (113573055)

CSS

New Features

  • Added support for the safe keyword in flexbox properties. (274304@main) (118000717)
  • Added support for CSS style container queries. (274481@main) (122800215)

Resolved Issues

  • Fixed getComputedStyle() to work with functional pseudo-elements like ::highlight(). (274846@main) (117864743)

History

Resolved Issues

  • Fixed the properties of History to throw a SecurityError when not in a fully active Document. (274260@main) (118750576)

HTML

New Features

  • Added support for the shadowrootclonable attribute and aligned with declarative shadow root standards changes. In particular, web developers will now have to set this attribute if they want their declarative shadow root to be clonable. (274727@main) (123006751)

JavaScript

Resolved Issues

  • Fixed several issues:
    • direct eval() in a default value expression inside a rest parameter creates a variable in the environment of the function rather than the separate one of the parameters;
    • a ReferenceError is thrown when accessing a binding, which is defined inside rest parameter, in eval(), or a closure created in a default value expression of a preceding parameter, but only if there is a var binding by the same name;
    • a closure, created in the default value expression inside a rest parameter, is created in a different VariableEnvironment of the function than its counterparts in preceding parameters which causes the incorrect environment to be consulted when querying or modifying parameter names that are “shadowed” by var bindings. (274109@main) (121961421)

Media

Resolved Issues

  • Fixed pseudo-element font size calculation to fix subtitle size in fullscreen mode. (274480@main) (122584350)

Deprecations

  • Removed non-standard VTTRegion.track. (274936@main) (123172214)

Networking

Resolved Issues

  • Fixed upgrading inactive or passive subresource requests and fetches in would-be mixed security contexts to match standards. (274409@main) (101678657)
  • Fixed loading WebArchives with a non-persistent datastore. (274565@main) (122290562)

Rendering

Resolved Issues

  • Fixed backdrop-filter to apply to the border area of an element with a border-radius. (274757@main) (122295068)

SVG

New Features

  • Added support for the turn unit in <angle>. (274778@main) (120840743)

Resolved Issues

  • Fixed the UA stylesheet for links in SVGs to apply cursor: pointer matching standards. (274422@main) (122715957)

URLs

Resolved Issues

  • Fixed the URL parser to parse URLs that include authority and a backslash after the host. (274915@main) (119219832)

Web API

Resolved Issues

  • Fixed changing HTMLCanvasElement width or height causing intermediate buffer allocations. (274135@main) (122309325)
  • Fixed canvas captureStream stuttering with WebGL. (274454@main) (122471664)
  • Fixed DOM Range to correctly account for CDATASection nodes. (274346@main) (122608224)

Web Inspector

Deprecations

  • Disabled the network throttling experimental feature. (274112@main) (122327408)

March 06, 2024 10:50 PM

March 05, 2024

WebKit Features in Safari 17.4

Surfin’ Safari

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, macOS Ventura, macOS Monterey, and in visionOS 1.1.

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 <input type="checkbox" switch>, 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 <input type="checkbox" switch> 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.

screenshot of all the form controls, now laid out in a vertical directionTry this demo of vertical form controls in a browser that has support.

Horizontal Rules inside Select

You can use an <hr> element (a horizontal rule) inside a <select> element to draw a separator line. WebKit shipped support in Safari 17.0 on macOS. Now, Safari 17.4 on iOS 17.4, iPadOS 17.4, and in visionOS 1.1 also has support.

Safari window floating in front of mountains in Vision Pro, with a a select menu open on a web page, showing lines between list items

Try a demo and read the story of how hr in select was supported years ago, went away, and is now restored.

And more

WebKit for Safari 17.4 also adds support for the showPicker() method for <input type="date"> 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 <html>. And the :root pseudo-element refers to the root element in the DOM — the html element. CSS Scoping lets you use <style> @scope to reset the scoping root to a certain element, to the parent of the <style> element.

<article id="my-component">
  <style>
    @scope {
      h1 { font-size: 4rem; }
    }
  </style>
  <h1>This is 4rem text.</h1>
</article>

<h1>This will not be styled by the CSS above.</h1>

In this case, because <article> is the direct parent of <style> @scope, all of the styles defined inside @scope will only impact article and the content inside article. Nothing outside article is affected.

But that’s not all CSS Scoping can do. Let’s imagine we want to apply styles to a sidebar, but we don’t want those styles to apply to everything in the sidebar. We can use @scope to create a donut of sorts — with a hole in the middle where the styles don’t apply.

@scope (aside) to (section) {
  h2 {
    font-size: 3rem;
  }
}
<aside id="my-sidebar">
  <h2>This is 3rem text.</h2>
  <section>
    <h2>This is not styled by the CSS above.</h2>
  </section>
</aside>
You can try this demo in a browser with support.

By defining a scoping root with a scope-start selector (aside) and a scoping limit with a scope-end selector (section), we can effectively stop the cascading of the styles.

Also, anytime you use CSS Scoping, it radically changes what happens when there’s a tie in specificity.

Since the creation of CSS, when multiple selectors have equal specificity, the one that appears last in the CSS cascade is the one that gets applied. For example, if this is your CSS:

.blue h1 { color: blue; }
.yellow h1 { color: yellow; }

Then this is your result.

<section class="blue">
  <section class="yellow">
    <h1>This headline is yellow.</h1>
  </section>
</section>

<section class="yellow">
  <section class="blue">
    <h1>This headline is yellow.</h1>
  </section>
</section>

The headline is always yellow, because .yellow comes later in the CSS file. The order in the HTML does not matter.

But with scoping, the selector that applies to an element that’s closer in the DOM to the scoping root is the one that will apply when their specificities are tied.

Let’s use @scope instead of descendant selectors:

@scope (.blue) { 
  h1 { color: blue; }
}
@scope (.yellow) {
  h1 { color: yellow; }
}

Now, the headline color is determined by the DOM order in HTML, not the cascade order in CSS:

<section class="blue">
  <section class="yellow">
    <h1>This headline is yellow.</h1>
  </section>
</section>

<section class="yellow">
  <section class="blue">
    <h1>This headline is blue!</h1>
  </section>
</section>

The headline is yellow when .yellow is the closer ancestor, and it’s blue when .blue is the closer ancestor.

This is a fundamental change to how CSS works, so don’t get caught off guard. Use CSS Scoping with a lot of thought and care.

Note that a selector like .blue h1 { } has higher specificity than a selector like @scope (.yellow){ h1 { }}. The specificity of the scoping root’s selector is not added to the specificity of the selectors inside the @scope rule, unlike Nesting. And .blue h1 is higher specificity than h1.

WebKit for Safari 17.4 also expands the purpose of the :scope pseudo-class. When used inside a @scope block, :scope matches the block’s defined scope root. This provides a way to apply styles to the root of the scope from inside the @scope block itself. In the following example, :scope applies a border to the article element.

<article id="my-component">
  <style>
    @scope {
      :scope { border: 1px solid black; }    
      h1 { font-size: 4rem; }
    }
  </style>
  <h1>This is 4rem text.</h1>
</article>
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 ⓘ 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: "ⓘ" / "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 <video> and <source> elements, the web standard specified that the first file that’s recognized by the browser should be chosen and played. This put the burden on the developer to make sure the best files were listed before lesser-quality files.

<video>
   <source src="movie.webm">
   <source src="movie.av1">
   <source src="movie.mov">
</video>
Are you sure the first format listed is always a better choice than the rest?

This made sense in a simpler time, when there were just a few codecs available. Now, there are many codecs with different qualities. It’s not always possible for developers to know which file is the best one for a user to stream. And it can be impossible to put them in one specific order that’s best for all users.

A browser might easily be capable of playing several of the files offered, but one of those files could be compressed with a codec that the user’s device can decode using hardware, while the rest might only be decoded by software alone.

It’s definitely a better user experience to use hardware decoding. Doing so significantly impacts power usage and makes a battery last longer. So now, in WebKit for Safari 17.4, the best file for the user is chosen, instead of defaulting to the first file that has support. Video codecs with hardware decoding support on various Apple devices include VP9, h.264, HEVC and AV1.

WebVTT

WebKit for Safari 17.4 adds support for HTML character entities to WebVTT (Web Video Text Tracks Format), the technology used to add subtitles and captions to video files on the web. HTML entities are a way to write special characters without having the browser mistakenly think they are part of the HTML code. For example, &middot; represents the “·” character.

MediaStream

WebKit for Safari 17.4 adds support whiteBalanceMode to MediaStream. In photography, adjusting white balance is a technique for compensating for the fact that “white” is a different color under different lighting conditions. Sunlight is very blue, while indoor lights tend to be quite orange. Our brains automatically adjust, so as humans, we rarely notice. But cameras need technology to help them adjust color temperature so that the resulting photo or video has the kind of coloring people expect. Now modes for white balance are available for the MediaStream Image Capture API on the web.

SVG

WebKit for Safari 17.4 adds support for kernelUnitLengthX and kernelUnitLengthY to SVGFESpecularLightingElement.

WebGL

WebKit for Safari 17.4 adds support for four new WebGL extensions: EXT_clip_control, EXT_depth_clamp, EXT_polygon_offset_clamp, and WEBGL_polygon_mode.

Web Assembly

WebKit for Safari 17.4 enables extended constant expressions to support more advanced WebAssembly linking.

Web Inspector

Web Inspector for Safari 17.4 has two new features. First, when a page attempts to load a font URL blocked by Lockdown Mode, a message is logged to the Console.

Second, Web Inspector now groups load errors for source maps. Source map files are used for converting a combined or minified file back into its original state. Grouping load errors helps reduce noise while debugging. You can disable this behavior in Web Inspector Settings under Experimental settings.

Changes to Safari

Safari 17.4 itself includes three changes to the UI and user experience. First, you can now configure the Favorites Bar to show your bookmarks with only their icons. Edit the name of the bookmark in the favorites bar, and remove the name. The icon will remain.

Second, Safari 17.4 now supports webpage translation inside <iframe> elements.

And third, Safari 17.4 adds support for Apple Cash virtual card numbers and showing the user their Apple Cash balance when using AutoFill.

Safari Extensions

Safari 17.4 includes a change to web extensions that allows extensions to open Private Browsing windows even when they don’t have access to Private Browsing.

Web Authentication

WebKit for Safari 17.4 adds support for WebAuthn’s PublicKeyCredentials.getClientCapabilities() function. Use it to find out which WebAuthn features are supported. It returns a Promise of a record<DOMString, boolean> containing capabilities and their values.

Bug Fixes and more

In addition to all the new features, WebKit for Safari 17.4 includes work polishing existing features.

Accessibility

  • Fixed exposing the correct <summary> element role. (13661104)
  • Fixed non-accessible content within iframes with ARIA roles. (104611075)
  • Fixed VoiceOver word echo on text inputs with a combobox role. (112488137)
  • Fixed an issue where innerHTML and innerText changes to labels did not update their corresponding input element’s accessibility title. (113872525)
  • Fixed <details> and <summary> elements not included in VoiceOver form controls menu or list. (117308226)
  • Fixed comboboxes not notifying assistive technologies when aria-activedescendant changes. (117747058)
  • Fixed toggling accessibility preferences to correctly update form control appearance. (117914468)
  • Fixed: Removed the default ARIA-level heading for a heading role, matching removal from ARIA specifications. (119059172)
  • Fixed text missing from accessibility labels for many common shadow DOM scenarios. (120223342)

Browser Changes

  • Fixed loading a ⌘Click fragment link in a background tab. (119079650)

CSS

  • Fixed the default link color contrast for the dark color scheme. (61149466)
  • Fixed getComputedStyle() for invalid pseudo-elements. (98504661)
  • Fixed querySelector() to not throw an exception for -webkit- prefixed pseudo-elements. (99299129)
  • Fixed :user-invalid triggering while typing a date. (110687369)
  • Fixed: Updated text-transform: full-size-kana to align with Unicode 15. (111508663)
  • Fixed contain: inline-size breaking grid-template-rows: auto. (113915953)
  • Fixed svh and dvh units being unexpectedly equal when the Safari tab bar is not visible. (115085360)
  • Fixed mixed-blend-mode to blend correctly against the root background. (115688282)
  • Fixed backdrop-filter with many interoperability improvements. (115703346)
  • Fixed oklab and oklch lightness value clamping. (116195533)
  • Fixed flex layout invalidation in cases where the content of a flex item changes or style changes impact the preferred widths computation of its items. (117181858)
  • Fixed selection gaps to get painted with the expected ::selection pseudo-element color. (117796745)
  • Fixed parsing and serialization of -webkit- prefixed pseudo-elements. (118081134)
  • Fixed ::backdrop to be allowed after ::slotted(). (119015204)
  • Fixed to allow :checked and :indeterminate to match at the same time. (119075969)
  • Fixed grid with size containment and min-height not sizing row correctly. (119736473)
  • Fixed computing values of basic shape rect() and xywh() as the equivalent inset(). (119739406)
  • Fixed poor performance with :has(+ :not(.class)) pseudo-class selector. (119819247)
  • Fixed CSS content computed value serialization. (120061551)
  • Fixed pseudo-element parsing in getComputedStyle() and KeyframeEffect.prototype.pseudoElement so they require them starting with :: (or : for 4 legacy pseudo-elements). (120170550)
  • Fixed CSS linear() easing. (120290721)
  • Fixed named at-rule container getting skipped when the container is named in a :host selector. (120428386)
  • Fixed :not(:has(:not(foo))) getting misclassified as scope breaking. (120492012)
  • Fixed the name for a ::slotted pseudo-element in a container query getting resolved against the wrong scope. (122224135)
  • Made -apple- prefixed pseudo-elements no longer valid. (120268884)

Forms

  • Fixed <select> not refreshing the dropdown after an <option> is removed on iPad. (88292987)
  • Fixed text-indent to affect the selected file(s) label for file inputs. (105223868)
  • Fixed dir=auto to work for hidden, password, submit, reset, and button input types, made dirname work for password and submit input types, and removed dirname support from number input types. (113127508)
  • Fixed serialization of autocomplete with a webauthn token. (116107937)
  • Fixed <option> elements outside of an <optgroup> getting added to the preceding group. (117930480)

Fullscreen

  • Fixed viewport units to be correct after entering and exiting fullscreen mode on iOS, iPadOS, and in visionOS. (120496571)

HTML

  • Fixed the system-ui font family within <canvas>. (117231545)
  • Fixed <progress> to use the page’s preferred rendering update interval. (118976548)
  • Fixed missing support for the direction attribute in the list of attributes whose values are matched case-insensitively with attribute selectors. ( (119432066)

JavaScript

  • Fixed stringification algorithm of the Function constructor to match specifications. (102065151)
  • Fixed block-level function declarations to have correct scope in global code and aligned the detection of hoistable block-level legacy function declarations with the spec. (113880075)
  • Fixed an edge case with detecting a semantic error in generators. (117497786)
  • Fixed Temporal API to throw TypeErrors for unexpected primitives. (117992134)
  • Fixed Temporal options handling to align with the specification. (118088676)
  • Fixed Temporal.Now.timeZone() to be updated to timeZoneId(). (118674314)

Loading

  • Fixed Link-stylesheet elements to not fire load events for non-text/css and non-2XX responses. (116112223)
  • Fixed link-stylesheet elements to not fire load events for non-2XX responses such as 3XX responses that do not redirect. (116331826)

Lockdown Mode

  • Fixed Lockdown Mode disabling on sites with COOP and COEP HTTP headers. (119503109)

Media

  • Fixed WebVTT regions to position according to specifications. (23091897)
  • Fixed pausing MediaRecorder continuing to call ondataavailable at every timeslice event. (115979604)
  • Fixed an HEVC decoder issue when translating annexb data. (116768196)
  • Fixed WebVTT to treat negative percentages as invalid values. (117615681)
  • Fixed object-fit: fill on <video> elements. (118020922)
  • Fixed WebRTC calls not unmuting automatically after using Siri sometimes losing incoming audio. (118461093)
  • Fixed white bars across the top and bottom of fullscreen video playback while using Light Mode. (118530255)
  • Fixed the always empty video.buffered attribute. (118550061)
  • Fixed WebVTT to correctly parse region id settings. (118551267)
  • Fixed VideoEncoder produces no frames with latencyMode “realtime” when framerate/bitrate are not given. (118725549)
  • Fixed AV1-in-MP4 codec string not shown in Show Media Stats. (118850797)
  • Fixed getDisplayMedia frameRate always at 30 regardless of constraints. (118874132)
  • Fixed returning to fullscreen from picture-in-picture breaking subsequent touch input. (119832557)
  • Fixed HLS video captions where there are multiple text tracks available. ( (119839950)
  • Fixed fullscreen video not scaling to display size when the Safari window is in Full Screen App Mode. (119893556)
  • Fixed handling key renewal requests that cause playback errors for some DRM content. (120230860)
  • Fixed camera and mic activation failure due to media capability granting and activation order. (120510826)
  • Fixed paint-on captions shifting during playback. (120847946)
  • Fixed videos shifting up and down when fullscreen overlay controls appear or disappear. (120848395)
  • Fixed volume slider flickering when adjusting volume in Safari in visionOS. (120855936)
  • Fixed blocked encrypted sampled not getting enqueued after a CDM is attached to a SourceBuffer. (120879185)
  • Fixed video playback on Twitter.com in Safari in visionOS. (121391975)
  • Fixed[Netflix.com content that can become zoomed-in and cropped when in fullscreen mode. (121822831)
  • Fixed pseudo-element font size calculation to fix subtitle size in fullscreen mode. (122584350)

Rendering

  • Fixed incorrectly oriented Traditional Mongolian script characters.(93426525)
  • Fixed resizing behavior with writing-mode: vertical-rl or direction: rtl. (102620110)
  • Fixed opacity and rendering the root element background image. (115396444)
  • Fixed the color of the drop shadow to preserve its alpha channel. (115812347)
  • Fixed filters with outsets to repaint the entire filterRegion if GraphicsStyles are used. (115817290)
  • Fixed compositing the filter style transparency layers to not clip the destination context. (115901634)
  • Fixed a bug where the returned transform from getComputedStyle was incorrect. (117523629)
  • Fixed handling images with color spaces not supported by the backend to fallback to render in sRGB. (118238178)
  • Fixed check boxes and radio buttons to avoid floats. (118660695)
  • Fixed rendering for a <div> within a transformed parent <div> with overflow: hidden. (118901069)
  • Fixed rendering issues when editing text. (119833765)
  • Fixed offsetHeight and offsetWidth are 0 for an inline box wrapping a block. (119955792)
  • Fixed a floating element causing a list item bullet to be orphaned on constrained lines. (120022893)
  • Fixed incorrect inline box (hugging) outline painting in vertical writing modes. (120217559)
  • Fixed incorrect ch unit value in vertical-rl and vertical-lr when text-orientation is not upright. (120293590)
  • Fixed graphics artifacts when scrolling a Heroku app. (120373474)
  • Fixed overflow: hidden to not prevent CSS Subgrid from applying. (120848131)
  • Fixed the repaint area for underline text decorations. (121082290)
  • Fixed align-content and justify-content on scroll containers causing overflowing content to become inaccessible. (121366949)
  • Fixed rendering floats and an out-of-flow <br> element with clear. (121444267)
  • Fixed a line break at gaps between two inline elements in a container with white-space: nowrap. (121859917)
  • Fixed cropped first letter for custom fonts that report negative advance width. (121891210)
  • Removed margin-trim behavior for floats to match specification changes. (115794102)

Safari Extensions

  • Fixed sending an error back to the caller if an error occurs for scripting.executeScript(). (107996753)
  • Fixed an issue where scripts may not be removed after calling scripting.unregisterContentScripts(). (113171510)

Scrolling

  • Fixed unusable horizontal scrollbars for right-to-left, vertical-rl, or flexbox reverse mode elements. (104944522)
  • Fixed a scrollTo() followed by an animated scroll ending at the wrong scroll position. (117608836)
  • Fixed wheel overflow behavior with Shadow DOM elements. (118496293)
  • Fixed keyboard scrolling beyond the page getting stuck at a bad scroll offset. (120053910)

Storage

  • Fixed cases where website data is unexpectedly evicted. (119818267)

SVG

  • Fixed applying rx or ry exclusively via CSS having no effect. (113500023)
  • Fixed negative SVGTransform scale values to be correctly stringified. (118656892)
  • Fixed the layout of an SVG when it is inside an <iframe> without affecting the size of the <iframe>. (120178866)
  • Removed support for SVGRenderingIntent. (102516681)

URLs

  • Fixed CSS invoked URL parsing to always use UTF-8 as agreed by the W3C CSS WG. (114889625)

Web Animations

  • Fixed style invalidation for animations. (118500247)
  • Fixed a paused animation where currentTime is changed to 0 not restarting when unpaused. (118826588)

Web API

  • Fixed invalid coordinates on wheel and gesturechange events inside an iframe. (105243167)
  • Fixed HTMLAreaElement to align with the HTML Standard. (110028213)
  • Fixed the result of Range.getClientRects() and Range.getBoundingRect() for certain ranges. (112543805)
  • Fixed Scroll To Text Fragment to not scroll after dynamic stylesheet loads and the user has scrolled. (112608578)
  • Fixed SharedWorker referrer policy to default to its context referrer policy if none is provided in its script http response. (114625126)
  • Fixed URL encoding for Request‘s referrer feature and Response.redirect(). They now always use UTF-8. (115219660)
  • Fixed reprocessing <meta name="color-scheme"> when their name or content attribute changes. (115958450)
  • Fixed FetchResponse.formData() to parse headers names as case insensitive. (116742000)
  • Fixed declarative shadow trees to match the latest specifications. (117655691)
  • Fixed jiggling caused by repeated calls to scrollIntoView({ block: 'center' }). (117755250)
  • Fixed fullscreen warning banner to prevent cutting off long domain names. (118078137)
  • Fixed updating resizeBy and resizeTo to use int rather than float to align with specifications. (118872048)
  • Fixed the CookieChangeEvent to not be exposed when the Cookie Store API is disabled. (118902989)
  • Fixed Element.prototype.setAttributeNode() to not treat attribute names case insensitively. (119013600)
  • Fixed toggling the spellcheck attribute not toggling spelling markers on input elements. (119269616)
  • Fixed removing highlights in the Custom Highlights API. (119531671)
  • Fixed getElementsByName() to only return HTML elements, not SVG, MathML, or other types of elements. (120275680)
  • Fixed the button value for a pointerup event not matching the pointerdown event. (120429508)
  • Fixed a wheel event to fire on an element that has been re-inserted after document.open. (120893136)
  • Fixed Scroll To Text Fragment Text Directives to find text with additional unrendered white space in their node data. (120913588)
  • Fixed changing HTMLCanvasElement width or height causing intermediate buffer allocations. (122309325)
  • Fixed canvas captureStream stuttering with WebGL. ((122471664)

Web Inspector

  • Fixed Home Screen Web Apps in Simulator to be listed under a “Home Screen Web Apps” section in the device submenu of the Develop menu. (117742935)
  • Fixed the tan() function to not trigger the color picker. (118724061)

WebGL

  • Fixed Canvas WebGL context capture to WebCodecsVideoFrame not capturing all frames. (108459224)
  • Fixed: Improved performance of MSAA rendering, including antialiased default framebuffer and fixed PBO uploads of PVRTC1 textures. (117461678)
  • Fixed WebGL OffscreenCanvas returning the previously created WebGL1 context when asking for WebGL2. (119028794)
  • Fixed WebGL to be available in nested workers. (120279728)

WebKit

  • Fixed HTML content not displaying in a Simulator, affecting projects using the web extension project template. (121338366)

WebRTC

  • Fixed media tracks obtained with {"width":1920,"height":1080,"frameRate":24}. (61747755)
  • Fixed triggering resolution scaling in the case of WebRTC maintain-framerate degradationPreference. (121041723)
  • Fixed a bug that prevented HTML canvas elements from always being marked dirty on initialization. This could cause some video effects to have choppy animations. (121257960)

Updating to Safari 17.4

Safari 17.4 is available on iOS 17.4, iPadOS 17.4, macOS Sonoma 14.4, macOS Ventura, macOS Monterey and in visionOS 1.1.

If you are running macOS Ventura or macOS Monterey, you can update Safari by itself, without updating macOS. On macOS Ventura, go to  > System Settings > General > Software Update and click “More info…” under Updates Available.

To get the latest version of Safari on iPhone, iPad, or Apple Vision Pro, go to Settings > General > Software Update, and tap to update.

Feedback

We love hearing from you. To share your thoughts on Safari 17.4, find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. Or send a reply on X to @webkit. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your feedback on Safari UI, or your WebKit bug report about web technologies or Web Inspector. Filing issues really does make a difference.

Download the latest Safari Technology Preview on macOS to stay at the forefront of the web platform and to use the latest Web Inspector features.

You can also find this information in the Safari 17.4 release notes.

March 05, 2024 06:30 PM

February 28, 2024

An HTML Switch Control

Surfin’ Safari

We’re very excited to introduce a new HTML form control as part of Safari 17.4: a switch.

Two switches as seen on iOS, with the second switch using a custom CSS accent-color.

The HTML for this example looks roughly like this:

<style> .special { accent-color: papayawhip } </style>
<input type=checkbox switch checked>
<input type=checkbox switch checked class=special>

Switches are a popular control on mobile platforms as well as in a large variety of UI frameworks, but until now they were not built into the web platform. Seeing the widespread need for this control we decided to change that.

The way we approached this is consistent with how other new form controls have been added to HTML:

  • We wanted it to have the look and feel of the OS control by default. It should match the end user’s preferences, and they should be able to manipulate the “thumb” of the switch in various ways.
  • We wanted to ensure it was backward compatible. A browser that does not support <input type=url> will treat it as <input type=text>. Likewise, a browser that does not support <input type=checkbox switch> will treat it as <input type=checkbox>.
  • We wanted the markup and API to be familiar. It mirrors that of checkboxes, except that the :indeterminate pseudo-class never matches.
  • We wanted the control to be accessible. Under the hood, it uses the ARIA switch role, announcing the states “On” and “Off” just like a switch from the OS. On macOS, if you enable “Differentiate Without Color”, or on iOS, if you enable “On/Off Labels”, the switch will show accessibility indicators.
  • We wanted the control to be stylable. As with <input type=checkbox>, if you use appearance: none, you get full control over its appearance as a web developer. It goes even a bit further as we ensured all properties will have their initial values when you use appearance: none. (See also the experimental ::thumb and ::track pseudo-elements explained below for planned enhancements in this area.) Control over styling is more limited with appearance: auto (the default). The accent-color property is supported and will be applied to the switch’s “track” background, as demonstrated in the image above.
  • We wanted the control to support a wide variety of languages, and as such, it has vertical rendering support out of the box. (This is in line with how we recently added vertical rendering support to the existing form controls.)

We’d love to see what you do with it and what else you would like this control to do.

Switch versus checkbox

Generally, we recommend using a switch when the end user understands the user interface element as a setting that is either “on” or “off”. A checkbox is well suited for when the end user would understand the element as something to be selected.

Experimental ::thumb and ::track pseudo-elements

In Safari if you go to Settings → Feature Flags, you can enable “::thumb and ::track pseudo-elements”, which gives web developers more control over the individual parts that make up a switch: its thumb and track. Essentially, this turns a single element into three, one parent with two sibling children.

We decided not to ship these pseudo-elements for now to give the standardization process additional time to finalize how they should work. We also want to make sure that when we ship them, they work for the other HTML controls they are designed for, such as <input type=range>. This way @supports(::thumb) will be all the feature detection you need.

Interactive demos of switch

Feedback appreciated

We’d love to hear what you make of this new HTML form control. Send a tweet to @webkit to share your thoughts on this feature. You can find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your WebKit bug reports on WebKit features like this. Reporting issues makes an enormous difference.

You can also download the latest Safari Technology Preview to try out new web platform features like this before they appear in a Safari beta.

And finally, a big thank you to Lily Spiniolas for doing a lot of work on this feature during her internship at Apple. Not just prototyping an implementation in WebKit, but also creating a pull request for the HTML Standard and carefully thinking through many aspects of its design.

February 28, 2024 07:47 PM

February 22, 2024

Release Notes for Safari Technology Preview 189

Surfin’ Safari

Safari Technology Preview Release 189 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.

This release includes WebKit changes between: 273602@main…274066@main.

CSS

New Features

  • Added support for light-dark() function for color values. (273634@main) (117033939)
  • Added support for @starting-style. (273740@main) (121918611)

Resolved Issues

  • Fixed named at-rule container getting skipped when the container is named in a :host selector. (273987@main) (120428386)
  • Fixed the name for a ::slotted pseudo-element in a container query getting resolved against the wrong scope. (274050@main) (122224135)

Deprecations

  • Removed :-webkit-full-screen-ancestor pseudo-class. (273620@main) (100782937)
  • Removed :-webkit-full-screen-controls-hidden pseudo-class. (273619@main) (121323330)
  • Removed :-webkit-full-page-media pseudo-class. (273618@main) (121752962)
  • Removed :-webkit-full-screen-document pseudo-class. (273639@main) (121816310)

HTML

Resolved Issues

  • Fixed parsing a self-closing SVG script element. It now successfully executes. (273697@main) (121887875)
  • Fixed “about:blank” document.referrer initialization. (273830@main) (97689906)

JavaScript

Resolved Issues

  • Fixed throwing a RangeError if Set methods are called on an object with negative size property. (274009@main) (121310940)
  • Fixed eval() function from another realm to not cause a direct eval call. (273782@main) (121546048)
  • Fixed eval() call with ...spread syntaxt to be a direct call. (273788@main) (121547890)
  • Fixed programming style for bitwise and in setExpectionPorts. (273960@main) (122138733)

Rendering

Resolved Issues

  • Fixed Greek uppercase transforms failing for some characters. (274036@main) (90364897)
  • Fixed lingering boxes with content-visibility: hidden. (273602@main) (117916396)
  • Fixed parts of the content disappear when interacting with overflow:scroll, z-index and positioning (including Heroku apps). (273999@main) (120373474)
  • Fixed align-content and justify-content on scroll containers causing overflowing content to become inaccessible. (273737@main) (121366949)
  • Fixed line break at gaps between two inline elements in a container with white-space: nowrap. (121859917)
  • Fixed a floating element causing the latter half of a hyphenated word to disappear. (273836@main) (121889487)
  • Fixed cropped first letter for custom fonts that report negative advance width. (121891210)

SVG

Resolved Issues

  • Fixed SVG title to have display: none as the default UA style rule. (273991@main) (122185838)

Web API

Resolved Issues

  • Fixed history.pushState() and history.replaceState() to ignore the title argument. (273650@main) (75695791)
  • Fixed lang attribute in no namespace to only apply to HTML and SVG elements. (273726@main) (117795695)
  • Fixed spelling of clonable. (274063@main) (121516711)

Deprecations

  • Removed which from KeyboardEvent. (273701@main) (106580687)

Web Inspector

New Features

  • Added a Media details panel to Web Inspector when selecting a <video> or <audio> element in the Elements tab. (273777@main) (118865793)

Resolved Issues

  • Fixed font sizes in the Audits tab. (273615@main) (76162927)

WebAuthn

Resolved Issues

  • Fixed navigator.credentials.create() rejects with “NotAllowedError: Operation Failed” after a conditional UI request is aborted. (273918@main) (109936742)

WebGL

New Features

  • Enabled support for EXT_texture_mirror_clamp_to_edge, WEBGL_render_shared_exponent, and WEBGL_stencil_texturing. (273645@main) (121835897)

WebRTC

New Features

  • Added support for missing WebRTC stats. (273643@main) (121594743)

Resolved Issues

  • Fixed a bug that prevented HTML canvas elements from always being marked dirty on initialization. This could cause some video effects to have choppy animations. (273897@main) (121257960)
  • Fixed VideoTrackGenerator writer to close when its generator track (and all its clones) are stopped. (273778@main) (121835553)

February 22, 2024 01:10 AM

February 20, 2024

Carlos García Campos: A Clarification About WebKit Switching to Skia

Igalia WebKit

In the previous post I talked about the plans of the WebKit ports currently using Cairo to switch to Skia for 2D rendering. Apple ports don’t use Cairo, so they won’t be switching to Skia. I understand the post title was confusing, I’m sorry about that. The original post has been updated for clarity.

By carlos garcia campos at February 20, 2024 06:11 PM

February 19, 2024

Carlos García Campos: WebKitGTK and WPEWebKit Switching to Skia for 2D Graphics Rendering

Igalia WebKit

In recent years we have had an ongoing effort to improve graphics performance of the WebKit GTK and WPE ports. As a result of this we shipped features like threaded rendering, the DMA-BUF renderer, or proper vertical retrace synchronization (VSync). While these improvements have helped keep WebKit competitive, and even perform better than other engines in some scenarios, it has been clear for a while that we were reaching the limits of what can be achieved with a CPU based 2D renderer.

There was an attempt at making Cairo support GPU rendering, which did not work particularly well due to the library being designed around stateful operation based upon the PostScript model—resulting in a convenient and familiar API, great output quality, but hard to retarget and with some particularly slow corner cases. Meanwhile, other web engines have moved more work to the GPU, including 2D rendering, where many operations are considerably faster.

We checked all the available 2D rendering libraries we could find, but none of them met all our requirements, so we decided to try writing our own library. At the beginning it worked really well, with impressive results in performance even compared to other GPU based alternatives. However, it proved challenging to find the right balance between performance and rendering quality, so we decided to try other alternatives before continuing with its development. Our next option had always been Skia. The main reason why we didn’t choose Skia from the beginning was that it didn’t provide a public library with API stability that distros can package and we can use like most of our dependencies. It still wasn’t what we wanted, but now we have more experience in WebKit maintaining third party dependencies inside the source tree like ANGLE and libwebrtc, so it was no longer a blocker either.

In December 2023 we made the decision of giving Skia a try internally and see if it would be worth the effort of maintaining the project as a third party module inside WebKit. In just one month we had implemented enough features to be able to run all MotionMark tests. The results in the desktop were quite impressive, getting double the score of MotionMark global result. We still had to do more tests in embedded devices which are the actual target of WPE, but it was clear that, at least in the desktop, with this very initial implementation that was not even optimized (we kept our current architecture that is optimized for CPU rendering) we got much better results. We decided that Skia was the option, so we continued working on it and doing more tests in embedded devices. In the boards that we tried we also got better results than CPU rendering, but the difference was not so big, which means that with less powerful GPUs and with our current architecture designed for CPU rendering we were not that far from CPU rendering. That’s the reason why we managed to keep WPE competitive in embeeded devices, but Skia will not only bring performance improvements, it will also simplify the code and will allow us to implement new features . So, we had enough data already to make the final decision of going with Skia.

In February 2024 we reached a point in which our Skia internal branch was in an “upstreamable” state, so there was no reason to continue working privately. We met with several teams from Google, Sony, Apple and Red Hat to discuss with them about our intention to switch from Cairo to Skia, upstreaming what we had as soon as possible. We got really positive feedback from all of them, so we sent an email to the WebKit developers mailing list to make it public. And again we only got positive feedback, so we started to prepare the patches to import Skia into WebKit, add the CMake integration and the initial Skia implementation for the WPE port that already landed in main.

We will continue working on the Skia implementation in upstream WebKit, and we also have plans to change our architecture to better support the GPU rendering case in a more efficient way. We don’t have a deadline, it will be ready when we have implemented everything currently supported by Cairo, we don’t plan to switch with regressions. We are focused on the WPE port for now, but at some point we will start working on GTK too and other ports using cairo will eventually start getting Skia support as well.

By carlos garcia campos at February 19, 2024 01:27 PM

February 16, 2024

How to use Media Source Extensions with AirPlay

Surfin’ Safari

Media Source Extensions (MSE) is a popular way to provide streaming video on the web. It gives JavaScript control of the way bytes are sent to the browser for playback. At the 2023 Worldwide Developer conference, Apple announced a new Managed Media Source API that improves on MSE with efficient video streaming and longer battery life for iOS and other devices.

However, MMS and MSE, by nature, are not compatible with AirPlay, which requires a unique playback URL. AirPlay allows you to start playback of your favorite videos on your phone, move them to your TV and then switch off that phone. An AirPlay-compatible URL can be of any format such as an mp4, mpeg-ts, or HTTP Live Streaming (HLS).

This post will guide you through providing both sources and, in the process, build out a demo example.

WebKit MSE + AirPlay Demo

Since MMS/MSE uses binary blobs appended to a SourceBuffer it won’t work with AirPlay. But, if you create an alternative source that can be served as an AirPlay-compatible URL, there is a way to get them to work together.

When it comes to an AirPlay-compatible alternative, HLS is an option that offers a great deal of efficiency for users. There are numerous resources that can guide you in converting your video content to serve it with HLS. Apple offers a toolkit you can use and there are many other options as well.

const airplayURL = './video/demo.m3u8';
const videoURL = './video/demo.mp4';
const mediaType = 'video/mp4; codecs="avc1.640028"';

// Create a video element
const video = document.createElement('video');

// Set video element properties for the demo
video.controls = true;
video.loop = true;
video.muted = true;
video.autoplay = true;

In setting up the MediaSource, it’s easy to use feature detection to use Managed Media Source API to offer power-efficient streaming on browsers that support it and gracefully fallback to MSE where its not available:

// Feature detect MMS and fallback to MSE
const MediaSource = self.ManagedMediaSource || self.MediaSource;
const source = new MediaSource();

We also need a way to offer both our Media Source and AirPlay sources at the same time. The HTML video element’s ability to define multiple sources will do just that. It was originally intended to allow a user-agent to choose the best format of the video to be played and fallback should it not be supported.

<video>
  <source src="format/video.m3u8" type="application/x-mpegURL">
  <source src="format/video.ogg" type="video/ogg">
  <source src="format/video.mp4" type="video/mp4">
  <source src="format/video.webm" type="video/webm">
</video>

The browser will look over the list of available formats from top to bottom. If no matches are found, or if decoding fails along the way, it will select the next element in the list.

We can make use of this behavior, combining the ability for the user-agent to choose the best format and allowing AirPlay to select a playable source. You’ll create a URL from your Media Source and add it to a video element as the first source. This URL is local to the user-agent and can’t be shared, as it has no meaning outside the local context. Then you add the AirPlay-compatible URL as the second source.

// Add MSE/MMS streaming source
const videoSource1 = document.createElement('source');
videoSource1.type = 'video/mp4';
videoSource1.src = URL.createObjectURL(source); // Create URL from MediaSource
video.appendChild(videoSource1);

// Add AirPlay-compatible HLS source
const videoSource2 = document.createElement('source');
videoSource2. type = 'application/x-mpegURL';
videoSource2.src = airplayURL;
video.appendChild(videoSource2);

Now when Safari detects that an alternative source is available in addition to the MediaSource URL object, it will display the familiar AirPlay icon to the video player control. Should the user select AirPlay, it will switch over from MSE to the AirPlay-compatible URL.

The streaming code for this demo is very basic and serves as an example of getting the bytes from the video to the browser.

document.onload = async () => {
  if (!MediaSource.isTypeSupported(mediaType)) {
    return console.log('Media type is not supported.');
  }

  await new Promise((resolve) => {
    source.addEventListener("sourceopen", resolve, { once: true });
    document.body.appendChild(video);
  });

  const sourceBuffer = source.addSourceBuffer(mediaType);

  async function loadSegment() {
    const response = await fetch(videoURL);
    const buffer = await response.arrayBuffer();
    await new Promise((resolve) => {
      sourceBuffer.addEventListener("updateend", resolve, { once: true });
      sourceBuffer.appendBuffer(buffer);
    });
  }

  if (typeof(source.onstartstreaming) !== 'undefined') {
    source.onstartstreaming = async () => {
      loadSegment();
    };
  } else loadSegment();
});

Feedback

Offering support for MMS/MSE and AirPlay is gives users the best of all worlds and the video element makes it easy to offer multiple sources. You can learn more about the Managed Media Source API proposal at the W3C, and learn about HTTP Live Streaming from Apple’s documentation.

We love to hearing from you. Send a tweet to @webkit to share your thoughts on this feature. Find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your WebKit bug reports on WebKit-powered features like this. Reporting issues and sharing your feedback makes an enormous difference.

February 16, 2024 06:35 PM

February 07, 2024

Release Notes for Safari Technology Preview 188

Surfin’ Safari

Safari Technology Preview Release 188 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.

This release includes WebKit changes between: 272449@main…273601@main.

Accessibility

New Features

  • Added support for the new CSS content alternative text syntax. (272455@main) (26942023)

Resolved Issues

  • Fixed role assignment for <header> inside <main> and sectioning elements. (273188@main) (48370244)
  • Fixed text missing from accessibility labels for many common shadow DOM scenarios. (272531@main) (120223342)
  • Fixed the mapping for the iOS accessibility framework to speak “switch button”, “on”, and “off” for <input type=checkbox switch>. (273206@main) (121215059)
  • Fixed comboboxes to expose their linked objects correctly. (273542@main) (121242926)

Animations

Resolved Issues

  • Fixed the transition property to produce the shortest serialization. (272513@main) (119822401)
  • Fixed the animation property to produce the shortest serialization. (272629@main) (120439368)

Browser Changes

Resolved Issues

  • Fixed loading a ⌘Click fragment link in a background tab. (272906@main) (119079650)
  • Fixed saving linked subresources when saving web page resources. (272925@main) (120491493)

CSS

New Features

  • Added supports() syntax for @import rules. (273591@main) (109060734)

Resolved Issues

  • Fixed getComputedStyle() for invalid pseudo-elements. (272543@main) (98504661)
  • Fixed oklab and oklch lightness value clamping. (272501@main) (116195533)
  • Fixed poor performance with :has(+ :not(.class)) pseudo-class selector. (272678@main) (119819247)
  • Fixed CSS content computed value serialization. (272476@main) (120061551)
  • Fixed pseudo-element parsing in getComputedStyle() and KeyframeEffect.prototype.pseudoElement so they require them starting with :: (or : for 4 legacy pseudo-elements). (272499@main) (120170550)
  • Fixed CSS linear() easing. (272613@main) (120290721)
  • Fixed: Aliased :-webkit-full-screen pseudo-class to :fullscreen. (272577@main) (120335917)
  • Fixed: Aliased :-webkit-any-link to :any-link and :matches() to :is(). (272559@main) (120337922)
  • Fixed getComputedStyle() pseudo-element parsing to support the full range of CSS syntax. (272649@main) (120471227)
  • Fixed :not(:has(:not(foo))) getting misclassified as scope breaking. (273177@main) (120492012)
  • Fixed @supports to correctly handle support for some -webkit prefixed pseudo-elements that were incorrectly treated as unsupported. (272726@main) (120577690)
  • Fixed updating media-query sensitive meta tags after style changes. (272947@main) (120854167)

Deprecations

  • Removed -webkit-alt and alt properties. (272480@main) (120051066)
  • Removed the non-standard resize: auto property. (273035@main) (120138995)
  • Made -apple- prefixed pseudo-elements no longer valid. (272538@main) (120268884)
  • Removed :-webkit-animating-full-screen-transition pseudo-class. (273529@main) (121302758)
  • Removed :-khtml-drag pseudo-class. (273261@main) (121303391)

Forms

Resolved Issues

  • Fixed text-indent to affect the selected file(s) label for file inputs. (272837@main) (105223868)

Loading

Resolved Issues

  • Fixed navigator.cookieEnabled to return false when cookies are blocked. (273522@main) (121284878)

Lockdown Mode

Resolved Issues

  • Fixed Lockdown Mode disabling on sites with COOP and COEP HTTP headers. (273243@main) (119503109)

Media

Resolved Issues

  • Fixed HLS video captions where there are multiple text tracks available. (272784@main) (119839950)
  • Fixed fullscreen video not scaling to display size when the Safari window is in Full Screen App Mode. (272733@main) (119893556)
  • Fixed handling key renewal requests that cause playback errors for some DRM content. (272592@main) (120230860)
  • Fixed paint-on captions shifting during playback. (272966@main) (120847946)
  • Fixed blocked encrypted sampled not getting enqueued after a CDM is attached to a SourceBuffer. (273340@main) (120879185)

Rendering

Resolved Issues

  • Fixed resizing a <textarea> element with 1rem padding. (273029@main) (90639221)
  • Fixed incorrectly oriented Traditional Mongolian script characters. (272454@main) (93426525)
  • Fixed handling images with color spaces not supported by the backend to fallback to render in sRGB. (273204@main) (118238178)
  • Fixed check boxes and radio buttons to avoid floats. (273047@main) (118660695)
  • Fixed rendering issues when editing text. (273320@main) (119833765)
  • Fixed a floating element causing a list item bullet to be orphaned on constrained lines. (272451@main) (120022893)
  • Fixed fully repainting form controls with visual overflow and writing-mode: vertical-rl. (272799@main) (120066970)
  • Fixed incorrect inline box (hugging) outline painting in vertical writing modes. (272512@main) (120217559)
  • Fixed incorrect ch unit value in vertical-rl and vertical-lr when text-orientation is not upright. (272536@main) (120293590)
  • Fixed the color correctness of the color matrix filter. (272891@main) (120795573)
  • Fixed overflow: hidden preventing CSS Subgrid. (273134@main) (120848131)
  • Fixed the repaint area for underline text decorations. (273126@main) (121082290)
  • Fixed rendering floats and an out-of-flow <br> element with clear. (273407@main) (121444267)

Scrolling

Resolved Issues

  • Fixed unusable horizontal scrollbars with a right-to-left element. (272466@main) (109858866)
  • Fixed wheel overflow behavior with Shadow DOM elements. (273181@main) (118496293)
  • Fixed keyboard scrolling beyond the page getting stuck at a bad scroll offset. (272957@main) (120053910)
  • Fixed a variety of issues by disabling Scroll Anchoring. (273238@main) (121236706)

Storage

Resolved Issues

  • Fixed cases where website data is unexpectedly evicted. (272951@main) (119818267)

Deprecations

  • Removed support for AppCache. (273297@main) (113343269)

SVG

Resolved Issues

  • Fixed negative SVGTransform scale values to be correctly stringified. (272885@main) (118656892)
  • Fixed the layout of an SVG when it is inside an <iframe> without affecting the size of the <iframe>. (272503@main) (120178866)
  • Fixed displaying an SVG element inside a <switch> element. (272831@main) (120732837)

Web API

New Features

  • Added support for CustomStateSet in custom elements and :state() pseudo-class. (272474@main) (120072599)

Resolved Issues

  • Fixed: Added support for AES-GCM in WebCrypto. (273488@main) (101040216)
  • Fixed removing highlights in the Custom Highlights API. (272723@main) (119531671)
  • Fixed unnecessarily unsetting the iframe fullscreen flag. (272462@main) (120052751)
  • Fixed getElementsByName() to only return HTML elements, not SVG, MathML, or other types of elements. (272530@main) (120275680)
  • Fixed the button value for a pointerup event not matching the pointerdown event. (273263@main) (120429508)
  • Fixed a wheel event to fire on an element that has been re-inserted after document.open. (272960@main) (120893136)
  • Fixed Scroll To Text Fragment Text Directives to find text with additional unrendered white space in their node data. (273016@main) (120913588)
  • Fixed Media Capture API to capture the camera. (273258@main) (121256297)

Deprecations

  • Removed support for KeyboardEvent.altGraphKey. (273379@main) (102980723)
  • Removed AES-CFB support from WebCrypto. (272615@main) (120000331)
  • Removed the non-standard KeyboardEvent.keyLocation. (273457@main) (121564228)

Web Extensions

Resolved Issues

  • Fixed browsing.scripting.executeScript to handle all valid argument types. (120727491)

WebAuthn

Resolved Issues

  • Fixed getClientCapabilities to align with WebAuthn standards to use a record type with camelCase values. (272998@main) (120442670)

WebGL

New Features

  • Enabled support for EXT_conservative_depth and NV_shader_noperspective_interpolation. (272979@main) (120907578)

Resolved Issues

  • Fixed WebGL to be available in nested workers. (272765@main) (120279728)

WebRTC

Resolved Issues

  • Fixed triggering resolution scaling in the case of WebRTC maintain-framerate degradationPreference. (273172@main) (121041723)

February 07, 2024 10:57 PM

February 01, 2024

The web just gets better with Interop 2024

Surfin’ Safari

The web is amazing. It makes collaborating, learning, and connecting easy for billions of people, because it’s intentionally designed to run on radically different devices.

It’s your job as a web developer to ensure your project works in every browser and for every user — and that can be hard to do. It’s a far easier undertaking when browsers have identical implementations of the web technology you use.

Identical implementations are accomplished through the web standards process, where people collaborate together to write extremely detailed technical documents that define each new web technology — right down to how website bugs should work.

One way to check and see if browsers follow the web standards is through automated testing. There are several shared repositories of such tests, including Web Platform Tests. WPT contains over 1.8 million tests, of which over 95% pass in all of the major browsers.

The Interop Project

The Interop project aims to improve interoperability by encouraging browser engine teams to look deeper into specific focus areas. Now, for a third year, Apple, Bocoup, Google, Igalia, Microsoft, and Mozilla pooled our collective expertise and selected a specific subset of automated tests for 2024.

Some of the technologies chosen have been around for a long time. Other areas are brand new. By selecting some of the highest priority features that developers have avoided for years because of their bugs, we can get them to a place where they can finally be relied on. And by selecting exciting new technology, we can ensure it’s interoperable from the beginning.

To better understand where interoperability is going in the future, let’s first take a look at the impact of Interop 2023.

Interop 2023

Interop 2023 was even more of an overwhelming success than Interop 2022. In January 2023, 48% of the chosen tests passed in all three of the major browser engines (in those shipped to users: Chrome and Firefox for desktop Linux, and Safari on macOS Monterey). A year later, that pass rate rose to 95% (in Chrome Dev and Firefox Nightly for desktop Linux, and Safari Technology Preview on macOS Ventura).

Screenshot of the graph of results from January to December 2023, available at https://wpt.fyi/interop-2023The success of Interop 2023, seen on the “Experimental” dashboard. The “Interop” line, in dark green, shows the percentage of tests that passed in all three — Chrome Dev, Firefox Nightly, and Safari Technology Preview.

What did Interop 2023 accomplish?

  • It ensured that all browsers have full support for P3 color, seven years after it started shipping.
  • Form controls now support vertical writing modes, for the first time in the web’s history.
  • CSS border-image now works as originally intended.
  • Subgrid, Container Queries, :has(), Motion Path, CSS Math Functions, inert and @property are now supported in every modern browser.
  • Improved Web APIs include Offscreen Canvas, Modules in Web Workers, Import Maps, Import Assertions, and JavaScript Modules.
  • The entire Media Queries 4 specification is now supported everywhere, with easier to use syntax.
  • Web Components got a boost with adoptedStyleSheets, ElementInternals, Form-Associated Custom Elements, and the basic behavior of Shadow DOM and Custom Elements.
  • Useful CSS pseudo-classes can now be relied on, with consistent cross-browser support for :nth-child(), :nth-last-child(), :modal, :user-valid, and :user-invalid.
  • Feature queries now have new support for detecting font features.
  • Font Palettes provide robust support for color fonts.
  • Significant progress made improving CSS Masking, HTML Forms, Pointer and Mouse Events, Scrolling, Transforms, URL, WebCodecs, and a bucket of bugs causing web compat issues.
  • And more.

We hope this work gives you a renewed sense of confidence to use these technologies. If you found any of them hard-to-use in the past, give them another try.

Interop 2023 had twenty-six focus areas, twenty of which are being retired as a success. Work will continue on Custom Properties, Pointer and Mouse Events, URL, and a new grouping called “Layout” — consisting of Flexbox, Grid, and Subgrid.

Interop 2024

Now, we are doing it all again for 2024. Ninety-six focus area proposals were submitted for consideration. Ultimately, sixteen were chosen. Grouping some of the new proposals together, and continuing some of the work from 2023, gives Interop 2024 a total of seventeen focus areas.

The Interop 2024 dashboardThe Interop 2024 dashboard, looking at the “stable” browsers (those currently in the hands of everyday people). Coincidentally, the overall Interop score is once again starting at 48%.

New this year, Microsoft Edge now has its own column on the Interop dashboard. This currently represents Edge and Edge Dev running on Windows 10.

The 2024 Focus Areas

Accessibility

Interop 2023 included an Accessibility Investigation project. Led by Apple’s accessibility team, the group worked diligently to create new accessibility testing infrastructure for WPT, and write over 1300 new accessibility tests. These tests have now been included in Interop 2024 as a focus area, encouraging browsers to increase their support.

The majority of new accessibility tests cover WAI-ARIA, in particular, the Roles Model and the Accessible Name and Description Computation (AccName). Together, these provide a consistent mechanism for conveying the purpose or intent of an element so assistive technology users understand what it is and what they can do with it.

Other new accessibility tests cover how those technologies are incorporated into host languages. For example, the HTML Accessibility API Mappings specification (HTML-AAM) defines the default accessibility semantics of HTML elements, along with related rules for how browsers work with features like the <label> element and image alt text. (See the html-aam/roles WPT tests as an example.)

Another new set of tests cover the accessibility of display: contents. This display mode in CSS provides a useful mechanism for removing the box around content — helpful when wanting to adjust the parent/child/grandchild relationships of content for the purposes of Flexbox or Grid. But it was off limits for use for years, because of the lack of accessibility in early implementations. Removing the box on an item completely removed all the contents of that box from the accessibility tree. Sighted users could still see the child content, but many users of assistive technology experienced it completely disappearing. Most of these problems have been fixed in browsers, but not all, not for every situation. These new tests are the next step toward full accessibility and interoperability.

By including these new Accessibility tests in Interop 2024, the hope is to fix every issue in all browsers. We want it to be easier for developers to create accessible sites and make the web better for everyone, including people with disabilities.

CSS Nesting

CSS Nesting is a focus area for Interop 2024 to ensure any differences are ironed out, and to provide you with the confidence to use it. The ability to nest CSS shipped in all four major browsers in 2023 — first in Chrome, Edge, and Safari in April/May. And then in Firefox in August.

The web standard changed slightly between May and August, relaxing the original requirement that every nested selector start with a symbol. Developers can now simply write article, rather than needing to use & article.

All of the implementations have since been updated, but there are still small bits that could benefit from attention to interoperability, especially as the final complex details of how Nesting works are settled in the CSS Working Group. Most of Safari’s test failures, for example, are about how nested CSS interacts with the Shadow DOM via :host.

Custom Properties

The @property at-rule started shipping in browsers over the last few years. As part of Interop 2023, the Custom Properties focus area rose from 4% of tests passing in all stable browsers to 7.6% passing — with 90.7% passing in all of the preview browsers. Firefox is the last browser to add support, which is currently in progress in Firefox Nightly. Since this work isn’t done yet, the focus area is being continued in 2024.

With @property, developers can declare CSS custom properties in a fashion similar to how browser engines define CSS properties — specifying its syntax, inheritance behavior, and initial value.

@property --size {
  syntax: "<length>";
  inherits: false;
  initial-value: 0px;
}

This allows you to do things in CSS that were impossible before, like animating gradients or certain parts of transforms.

Declarative Shadow DOM

Declarative Shadow DOM is a declarative API that lets you create reusable widgets and components by using only HTML — no JavaScript is necessary. It’s been supported in Safari 16.4 since March 2023, and in Chrome 90 since April 2021. Firefox has an implementation in Firefox Nightly.

Declarative Shadow DOM was one of the often-asked-for features in the State of HTML 2023 survey, so it was chosen to be part of Interop 2024 to ensure it becomes interoperable across all browsers.

Font size adjust

The font-size-adjust property is a great example of the usefulness of placing attention on older technology. Firefox first implemented font size adjust in 2008, but it was rarely used or even discussed by web designers and developers. The early spec evolved over time, adding support for more languages through the two-value syntax, and becoming easier to use with the from-font value.

The WebKit team implemented the basic version in Safari 16.4 and added the updates in September’s Safari 17.0. Mozilla updated their implementation in Firefox 118, also in September 2023. Both Safari and Firefox now pass 100% of all tests. Chrome began an experimental implementation in 2015, but has yet to ship it. Now with Interop 2024, it’s likely every browser will gain complete support.

Font size adjust provides a simple way to conform all the fonts used in a string of text to be the same visual size — so every character in 1.4rem-sized text, for example, has the same x-height — or cap height, ch width, ic width, or ic height. The two value syntax allows you to choose which measurement to conform.

This property is especially useful when you are mixing code with regular text, or mixing multiple languages together, and the different fonts within the same sentence have different sizes. With font size adjust you can avoid weirdly-big letters. No more fussing with font metrics to find a magic number that makes them all look the same size.

a code demo showing the visual consistency of the inked x-height of multiple font familiesThe CSS `font-size-adjust: from font` makes the Courier font adjust its size to match its x-height with that from Iowan Old Style, instead of typesetting the code to be visually larger. The size uniformity holds even when fallback fonts are used instead.

Learn more about font-size-adjust by watching What’s new in CSS from WWDC23.

HTTPS URLs for WebSocket

A quirky aspect of the WebSocket API is that you need to use non-HTTP(S) schemes: ws: (insecure) and wss:. As the URLs function otherwise identically to HTTP(S) URLs, this makes the API a bit frustrating to deal with. Based on web developer feedback the WebKit team decided to address this last year by making the API support HTTP(S) URLs as well. We shipped support in Safari 17.0.

This means that instead of writing:

function webSocketHandle(path) {
  const url = new URL(path, location);
  url.protocol = location.protocol === "https:" ? "wss:" : "ws:";
  return new WebSocket(url);
}
// ...
const ws = webSocketHandle(path);

You can now write the much more ergonomic:

const ws = new WebSocket(path);

By bringing this to Interop 2024, we hope other browsers will adopt it as well, making it universally available for web developers.

IndexedDB

IndexedDB is an API that provides powerful ways to store data client-side, in an object-oriented database. It started shipping in browsers in 2011, and over the years the web standard has kept evolving. Both version 2 and version 3 are supported by all major browsers. Version 2 is fully interoperable, but version 3 needs a bit of attention to bring up the quality of implementations. Being part of Interop 2024 will help ensure implementations are completed and aligned.

Layout

CSS Grid and Flexbox were both included in the original Interop project in 2021. Subgrid was added in Interop 2023. While all three layout methods are now in great shape, they still aren’t quite perfect. The tests for these three areas are now being combined into one Focus Area called Layout. Work will continue to ensure complex edge cases are more interoperable. Meanwhile, developers should absolutely feel confident using these three technologies, since all browsers have solid support for Flexbox, Grid, and now Subgrid.

Pointer and Mouse Events

Pointer events are DOM events that are fired for a pointing device. They create a single DOM event model to handle pointing input devices such as a mouse, pen/stylus, or touch with one or more fingers. This API first started shipping in browsers in 2012, and landed everywhere by 2019, but still had rocky interoperability.

In 2022, the Interop team launched an Investigation Project to look deeper into the current state of Pointer and Mouse Events, in an effort to clarify consensus and write tests that captured the state of that consensus. For Interop 2023, those tests enabled Pointer and Mouse Events to be a Focus Area, where the test pass rate was part of the Interop 2023 dashboard and score. Over the year, Pointer and Mouse Events rose from a test pass rate of 34% to 81% — the most significant progress of any area.

While passing 81% of tests is a significant improvement, there is more work to do, therefore Pointer and Mouse Events will continue to be a Focus Area for 2024.

Popover

The new popover attribute in HTML provides a built-into-the-browser way to have an element pop into view on the top layer of a page. If you are creating an overlay over the entire web page, the dialog element is the best option. But when you want to turn any other element into a popup message, user interface, or other kind of content that appears and disappears, the popover element provides a framework to do it.

Support for popover shipped in Chrome 114 and Safari 17.0 in 2023. Firefox currently has support in progress in Firefox Nightly. Being part of Interop 2024 will ensure this highly desired feature has a fantastic start.

Relative Color Syntax

Relative Color Syntax is a new way to define colors in CSS that allows you do so while referring to another color. You can, for instance, lighten or darken an existing color by a certain amount. You can take a color variable, adjust the saturation, and assign the new color to a second variable. Relative Color Syntax can be especially powerful when creating a design system.

a still from the WWDC session teach how relative color syntax worksLearn more about Relative Color Syntax by watching What’s new in CSS from WWDC23.

Safari 16.4 was the first browser to ship support, in March 2023. Chrome 119 and Edge 119 shipped support in Oct and Nov 2023. Currently, none of the implementations have support for using currentcolor with Relative Color Syntax.

The Relative Color Syntax focus area for Interop 2024 doesn’t test overall support of Relative Color Syntax. It’s narrowly focused on whether or not currentcolor is supported, and includes tests of out-of-gamut behavior — checking to see what happens on displays that don’t have support for P3 color. Inclusion in Interop 2024 will help these final bits get done.

requestVideoFrameCallback

The <video> element provides powerful functionality for putting video on the web. But often, developers want and need to do more. The HTMLVideoElement interface provides special properties and methods for manipulating video objects in JavaScript. And one of those methods is requestVideoFrameCallback(). It lets you perform per-video-frame operations on video in an efficient manner — operations like video processing or analysis, painting to canvas, and synchronization with audio sources.

Supported since Chrome 83 and Safari 15.4, inclusion in Interop 2024 will help browsers complete and polish our implementations.

Scrollbar styling

The scrollbar styling focus area includes two CSS properties that can be used to style scrollbars. The scrollbar-width property provides three values: auto, thin, and none. The auto value is the default width; thin provides a thinner scrollbar; and none hides the scrollbar while still allowing content to scroll. Firefox 64 implemented support in December 2018, and it just shipped in Chrome 121 and Edge 121.

The scrollbar-gutter property lets you reserve space for the scrollbar, so the layout is the same whether or not a scrollbar is present. The scrollbar-gutter: stable rule lets you tell the browser to reserve space for a scrollbar, even when a scrollbar isn’t there. This can prevent layout shifts from happening between states where scrollbars are needed or not needed. It shipped in Chrome 94, Edge 94 and Firefox 97, in 2021–22.

Safari has the most work to do to complete this Focus Area. Chrome and Firefox already pass 100% of the tests. Ironically, it was Safari who first provided the ability to style scrollbars with nine pseudo-elements, ::-webkit-scrollbar-*, back in 2009. However that approach to styling scrollbars never became an official CSS web standard. The CSS Working Group instead opted for a far simpler approach.

@starting-style and transition-behavior

This Focus Area brings attention to two new features for controlling animation. Both shipped in Chrome 117 and Edge 177 in Sept 2023.

The @starting-style rule in CSS lets you define starting values for a particular element. This is needed when the element is about to go through a transition. It also provides a way for transitioning in or out of display:none.

.alert {
  transition: background-color 2s;
  background-color: green;
  @starting-style {
    background-color: transparent;
  }
}

In the above example, the background-color will transition from transparent to green when the element is appended to the document.

Previously, only animations could animate discretely-animatable properties. The transition-behavior property in CSS expands that capability to CSS transitions, paving the way for transitioning the display property when showing or hiding elements.

Text Directionality

The direction in which text flows is a vital aspect of typesetting on the web. Some languages flow from left-to-right, while others flow from right-to-left. One of the many bits of technology supporting text direction is the dir attribute. It lets you specifically mark any HTML element with the direction: left, right, or auto — where auto asks the browser to guess from the first letter. The interaction of directionality and shadow trees was not well-defined until recently. Now that it’s been addressed at a standards level, adding it to Interop 2024 helps us ensure implementations align as well.

text-wrap: balance

Web designers have long wished for a way to prevent very short or one-word lines of text — often known as widows or orphans. Since the advent of responsive web design and the lack of control over the width of columns, this desire has gotten even more challenging. The text-wrap property provides you with multiple options for telling the browser how to wrap text with different methods for calculating line breaks for specific use cases.

The text-wrap: balance rule is a great solution for headlines. It balances a few lines of text so that each line has about the same amount of text as the others. It shipped in Chrome 114 and Firefox 121, and is implemented in Safari Technology Preview.

Interop 2024 also includes tests of how text-wrap-mode, text-wrap-style, and white-space-collapse behave. The CSS Working Group recently changed to how these longhands interact with each other, so support is currently uneven between browsers. Interop 2024 will help ensure all browser engines update to the latest web standards.

URL

URLs are one of the most fundamental parts of the web. Without them, the web would not exist. But like many things invented very early in the history of the web, support has yet to be fully interoperable. To improve this, the WHATWG wrote the URL Living Standard packed with details on exactly how URLs should work. The tests supporting this web standard were a focus area for Interop 2023, improving the pass rate from 77% to 85%. To ensure interoperability, the work in this area will continue in 2024.

Safari is proud to lead the pack, passing 99.7% of the tests. Improvements in other browsers will help ensure websites work correctly everywhere.

The 2024 Investigation projects

Interop 2024 also includes three investigation areas. These are “homework projects” for the Interop team to work on. All three this year are about writing and making it possible to run more tests — Accessibility Testing, Mobile Testing, and WebAssembly Testing. The Mobile Testing investigation project aims to complete the infrastructure needed at WPT to be able to test browsers on mobile operating systems, potentially to include those scores on the Interop project dashboard in the future.

While two of the three investigations are projects continuing from last year, they all are starting 2024 at zero percent done. Each team involved will set new goals for this year, and the dashboard will report progress on those goals.

Track the progress

Keep up with the progress of Interop 2024 throughout the year, on the Interop 2024 dashboard.

Our Commitment

We continue to believe that interoperability is one of the fundamental pillars that makes the web such a success. Our efforts in Interop 2022 and 2023 demonstrate how deeply we care about the web. We are excited to again collaborate with our colleagues in seizing this opportunity help the web work better for everyone.

February 01, 2024 05:00 PM

WPE WebKit Blog: Use Case: Server-side headless rendering

Igalia WebKit

WPE and server-side headless rendering

In many distributed applications, it can be useful to run a light web browser on the server side to render some HTML content or process images, video and/or audio using JavaScript.

Some concrete use-cases can be:

  • Video post-production using HTML overlays.
  • Easy 3D rendering with WebGL that can be broadcasted as a video stream.
  • Reusing the same JavaScript code between a frontend web application and the backend processing.

WPE WebKit is the perfect solution for all those use cases as it offers a lightweight solution which can run on low-end hardware or even within a container. It provides a lot of flexibility at the moment of choosing the backend infrastructure as WPE WebKit can, for instance, run from within a container with a very minimal Linux configuration (no need for any windowing system) and with full hardware acceleration and zero-copy of the video buffers between the GPU and the CPU.

Additionally, the fact that WPE WebKit is optimized for lower-powered devices, makes it also the perfect option for server-side rendering when scaling commercial deployments while keeping cost under control, which is yet another important factor to take into account when considering cloud rendering.

February 01, 2024 12:00 AM

January 29, 2024

WPE WebKit Blog: A New WPE Backend Using EGLStream

Igalia WebKit

What is a WPE Backend?

Depending on the target hardware WPE may need to use different techniques and technologies to ensure correct graphical rendering. To be independent of any user-interface toolkit and windowing system, WPE WebKit delegates the rendering to a third-party API defined in the libwpe library. A concrete implementation of this API is a “WPE backend”.

WPE WebKit is a multiprocess application, the end-user starts and controls the web widgets in the application process (which we often call “the UI process” while the web engine itself uses different subprocesses: WPENetworkProcess is in charge of managing network connections and WPEWebProcess (or “web process”) in charge of the HTML and JavaScript parsing, execution and rendering. The WPE backend is at a crossroads between the UI process and one or more web process instances.

Diagram showing a box for the WPE backend in between the UI process and WPEWebProcess

The WPE backend is a shared library that is loaded at runtime by the web process and by the UI process. It is used to render the visual aspect of a web page and transfer the resulting video buffer from the web process to the application process.

Backend Interfaces

The WPE backend shared library must export at least one symbol called _wpe_loader_interface of type struct wpe_loader_interface as defined in the libwpe API. Presently its only member is load_object, a callback function that receives a string with an interface name and returns concrete implementations of the following interfaces:

The names passed to the .load_object() function are the same as those of the interface types, prefixed with an underscore. For example, a .load_object("_wpe_renderer_host_interface") call must return a pointer to a struct wpe_renderer_host_interface object.

Example C code for a load_object callback.
static struct wpe_renderer_host_interface = { /* ... */ };
static struct wpe_renderer_backend_egl_interface = { /* ... */ };

static void*
my_backend_load_object(const char *name)
{
    if (!strcmp(name, "_wpe_renderer_host_interface"))
        return &my_renderer_host;
    if (!strcmp(name, "_wpe_renderer_backend_egl_interface"))
        return &my_renderer_backend_egl;

    /* ... */

    return NULL;
}

struct wpe_loader_interface _wpe_loader_interface = {
    .load_object = my_backend_load_object,
};

Each of these interfaces follow the same base structure: the struct members are callback functions, all interfaces have create and destroy members which act as instance constructor and destructor, plus any additional “methods”. The pointer returned by the create callback will be passed as the object “instance” of the other methods:

struct wpe_renderer_host_interface {
  void* (*create)(void);
  void  (*destroy)(void *object);
  /* ... */
};

In the UI process side WPE WebKit will create:

  • One “renderer host” instance, using wpe_renderer_host_interface.create().
  • Multiple “renderer host client” instances, using wpe_renderer_host_interface.create_client(). These are mainly used for IPC communication, one instance gets created for each web process launched by WebKit.
  • Multiple “view backend” instances, using wpe_view_backend_interface.create(). One instance is created for each rendering target in the web process.

In each web process—there can be more than one—WPE WebKit will create:

  • One “renderer backend EGL” instance, using wpe_renderer_backend_egl_interface.create().
  • Multiple “renderer backend EGL target” instances, using wpe_renderer_backend_egl_target_interface.create(). An instance is created for each new rendering target needed by the application.
How about wpe_renderer_backend_egl_offscreen_target_interface?

The rendererBackendEGLTarget instances may be created by the wpe_renderer_backend_egl_target_interface, or the wpe_renderer_backend_egl_offscreen_target_interface depending on the interfaces implemented in the backend.

Here we are only focusing on the wpe_renderer_backend_egl_target_interface that is relying on a classical EGL display (defined in the rendererBackendEGL instance). The wpe_renderer_backend_egl_offscreen_target_interface may be used in very specific use-cases that are out of the scope of this post. You can check its usage in the WPE WebKit source code for more information.

These instances typically communicate with each others using Unix sockets for IPC. The IPC layer must be implemented in the WPE backend itself because the libwpe interfaces only pass around the file descriptors to be used as communication endpoints.

From a topological point of view, all those instances are organized as follows:

From an usage point of view:

  • The rendererHost and rendererHostClient instances are only used to manage IPC endpoints on the UI process side that are connected to each running web process. They are not used by the graphical rendering system.
  • The rendererBackendEGL instance (one per web process) is only used to connect to the native display for a specific platform. For example, on a desktop Linux, the platform may be X11 where the native display would be the result of calling XOpenDisplay(); or the platform may be Wayland and in this case the native display would be the result of calling wl_display_connect(); and so on.
  • The rendererBackendEGLTarget (on the web process side) and viewBackend (on the UI process side) instances are the ones truly managing the web page graphical rendering.

Graphics Rendering

As seen above, the interfaces in charge of the rendering are wpe_renderer_backend_egl_target_interface and wpe_view_backend_interface. During their creation, WPE WebKit exchanges the file descriptors used to establish a direct IPC connection between a rendererBackendEGL (in the web process), and a viewBackend (in the UI process).

During the EGL initialization phase, when a new web process is launched, WebKit will use the native display and platform provided by the wpe_renderer_backend_egl_interface.get_native_display() and .get_platform() functions to create a suitable OpenGL ES context.

When WebKit’s ThreadedCompositor is ready to render a new frame (in the web process), it calls the wpe_renderer_backend_egl_target_interface.frame_will_render() function to let the WPE backend know that rendering is about to start. At this moment, the previously created OpenGL ES context is made current to be used as the target for GL drawing commands.

Once the threaded compositor has finished drawing, it will swap the front and back EGL buffers and call the wpe_renderer_backend_egl_target_interface.frame_rendered() function to signal that the frame is ready. The compositor will then wait until the WPE backend calls wpe_renderer_backend_egl_target_dispatch_frame_complete() to indicate that the compositor may produce a new frame.

What happens inside the .frame_will_render() and .frame_rendered() implementations is up to the WPE backend. As en example, it could set up a Frame Buffer Object to have the web content draw offscreen, in a texture that can be passed back to the UI process for further processing, or use extensions like EGLStream, or DMA-BUF exports to transfer the frame to the UI process without copying the pixel data.

Typically the backend sends each new frame to the corresponding view backend in in its .frame_rendered() function. The application can use the frame until it sends back an IPC message to the renderer target (in the web process) to indicate that the frame is not in use anymore and may be be freed or recycled. Although it is not a requirement to do it at this exact point, usually when a renderer backend receives this message it calls the wpe_renderer_backend_egl_target_dispatch_frame_complete() function to trigger the rendering of a new frame. As a side effect, this mechanism also allows controlling the pace at which new frames are produced.

Using EGLStream

EGLStream is an EGL extension that defines a mechanism to transfer hardware video buffers from one process to another efficiently, without getting them out of GPU memory. Although the extension is supported only in Nvidia hardware, it makes for a good example as it transparently handles some complexities involved, like buffers with multiple planes.

This backend uses the EGLStream extension to transfer graphics buffers from the web process, which acts as a producer, to the UI process acting as a consumer. The producer extension EGL_KHR_stream_producer_eglsurface allows creating a surface that may be used as target for rendering, then using eglSwapBuffers() finishes drawing and sends the result to the consumer. Meanwhile, in the consumer side, the EGL_NV_stream_consumer_eglimage extension is used to turn each buffer into an EGLImage.

The reference source code for this WPE backend is available in the WPEBackend-offscreen-nvidia repository, which has been tested with WPE WebKit 2.38.x or 2.40.x, and libwpe version 1.14.x.

Behold, the Future Belongs to DMA-BUF!

With the growing adoption of DMA-BUF for sharing memory buffers on modern Linux platforms, the WPE WebKit architecture will be evolving and, in the future, the need for a WPE Backend should disappear in most cases.

Ongoing work on WPE WebKit removes the need to provide a WPE backend implementation for most hardware platforms, with a generic implementation using DMA-BUF provided as an integral, built-in feature of WebKit. It will still be possible to provide external implementations for platforms that might need to use custom buffer sharing mechanisms.

From the application developer point of view, in most cases writing programs that use the WPE WebKit API will be simpler, with the complexity of the communication among multiple processes handled by WebKit.

Stream Setup

The steps needed to set up EGLStream endpoints need to be done in a particular order:

  1. Create the consumer.
  2. Get the stream file descriptor for the consumer.
  3. Send the stream file descriptor to the producer.
  4. Create the producer.

First, the consumer needs to be created:

EGLStream createConsumerStream(EGLDisplay eglDisplay) {
    static const EGLint s_streamAttribs[] = {
        EGL_STREAM_FIFO_LENGTH_KHR, 1,
        EGL_CONSUMER_ACQUIRE_TIMEOUT_USEC_KHR, 1000 * 1000,
        EGL_NONE
    };
    return eglCreateStreamKHR(eglDisplay, s_streamAttribs);
}

The EGL_STREAM_FIFO_LENGTH_KHR parameter defines the length of the EGLStream queue. If set to zero, the stream will work in “mailbox” mode and each time the producer has a new frame it will empty the stream content and replace the frame by the new one. If non-zero, the stream works work in “FIFO” mode, which means that the stream queue can contain up to EGL_STREAM_FIFO_LENGTH_KHR frames.

Here we configure a queue for one frame because in this case the specification of EGL_KHR_stream_producer_eglsurface guarantees that calling eglSwapBuffers() on the producer the call will block until the consumer retires the previous frame from queue. This is used as implicit synchronization between the UI process side and the web process side without needing to rely on custom IPC, which would add a small delay between frames.

The EGL_CONSUMER_ACQUIRE_TIMEOUT_USEC_KHR parameter defines the maximum timeout in microseconds to wait on the consumer side to acquire a frame when calling eglStreamConsumerAcquireKHR(). It is only used with the EGL_KHR_stream_consumer_gltexture extension because the EGL_NV_stream_consumer_eglimage extension allows setting a timeout on each call to eglQueryStreamConsumerEventNV() function.

Second, to initialize the consumer using the EGL_NV_stream_consumer_eglimage extension it is enough to call the eglStreamImageConsumerConnectNV() function.

Once the consumer has been initialized, you need to send the EGLStream file descriptor to the producer process. The usual way of achieving this would be using IPC between the two processes, sending the file descriptor in a SCM_RIGHTS message through an Unix socket—although with recent kernels using pidfd_getfd() may be an option if both processes are related.

When the file descriptor is finally received, the producer endpoint can be created using the EGL_KHR_stream_producer_eglsurface extension:

const EGLint surfaceAttribs[] = {
    EGL_WIDTH, width,
    EGL_HEIGHT, height,
    EGL_NONE
};
EGLStream eglStream = eglCreateStreamFromFileDescriptorKHR(eglDisplay, consumerFD);
EGLSurface eglSurface = eglCreateStreamProducerSurfaceKHR(eglDisplay, config, eglStream, surfaceAttribs);

As with pbuffer surfaces, the dimensions need to be specified as surface attributes. When picking a frame buffer configuration with eglChooseConfig() the EGL_SURFACE_TYPE attribute must be set to EGL_STREAM_BIT_KHR. From this point onwards, rendering proceeds as usual: the EGL surface and context are made active, and once the painting is done a call to eglSwapBuffers() will “present” the frame, which in this case means sending the buffer with the pixel data down the EGLStream to the consumer.

Consuming Frames

While on the producer side rendering treats the EGLStream surface like any other, on the consumer some more work is needed to manager the lifetime of the data received: frames have to be manually acquired and released once they are not needed anymore.

The producer calls eglQueryStreamConsumerEventNV() repeatedly to retire the next event from the stream:

  • EGL_STREAM_IMAGE_ADD_NV indicates that there is a buffer in the stream that has not yet been bound to an EGLImage, and the application needs to create a new one to which the actual data will be bound later.
  • EGL_STREAM_IMAGE_AVAILABLE_NV indicates that a new frame is available and that it can be bound to the previously created EGLImage.
  • EGL_STREAM_IMAGE_REMOVE_NV indicates that a buffer has been retired from the stream, and that its associated EGLImage may be released once the application has finished using it.

This translates roughly to the following code:

static constexpr EGLTime MAX_TIMEOUT_USEC = 1000 * 1000;
EGLImage eglImage = EGL_NO_IMAGE;

while (true) {
    EGLenum event = 0;
    EGLAttrib data = 0;

    // WARNING: The specification states that the timeout is in nanoseconds
    // (see: https://registry.khronos.org/EGL/extensions/NV/EGL_NV_stream_consumer_eglimage.txt)
    // but in reality it is in microseconds, at least with the version 535.113.01 of the NVidia drivers.
    if (!eglQueryStreamConsumerEventNV(display, eglStream, MAX_TIMEOUT_USEC, &event, &data))
        break;

    switch (event) {
      case EGL_STREAM_IMAGE_ADD_NV: // Bind an incoming buffer to an EGLImage.
          if (eglImage) eglDestroyImage(display, eglImage);
          eglImage = eglCreateImage(display, EGL_NO_CONTEXT, EGL_STREAM_CONSUMER_IMAGE_NV,
                                    static_cast<EGLClientBuffer>(eglStream), nullptr);
          continue; // Handle the next event.

      case EGL_STREAM_IMAGE_REMOVE_NV: // Buffer removed, EGLImage may be disposed.
          if (data) {
              EGLImage image = reinterpret_cast<EGLImage>(data);
              eglDestroyImage(display, image);
              if (image == eglImage)
                  eglImage = EGL_NO_IMAGE;
          }
          continue; // Handle the next event.

      case EGL_STREAM_IMAGE_AVAILABLE_NV: // New frame available.
          if (eglStreamAcquireImageNV(display, eglStream, &eglImage, EGL_NO_SYNC))
              break;

      default:
          continue; // Handle the next event.
    }

    /*** Use the EGLImage here ***/

    eglStreamReleaseImageNV(display, eglStream, eglImage, EGL_NO_SYNC);
}

The application is free to use each EGLImage as it sees fit. An obvious example would be to use it as the contents for a texture, which then gets painted in the “content” area of a web browser; or as the contents of the screen for an in-game computer that the player can interact with, enabling display of real, live web content as part of the gaming experience—now that would be a deeply embedded browser!

One Last Thing

There is a small showstopper to have EGLStream support working: currently when WPE WebKit uses surfaceless EGL contexts it sets the surface type to EGL_WINDOW_BIT attribute, while EGL_STREAM_BIT_KHR would be needed instead. A small patch is enough to apply this tweak:

diff --git a/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp b/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
index d5efa070..5f200edc 100644
--- a/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
+++ b/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
@@ -122,9 +122,11 @@ bool GLContextEGL::getEGLConfig(EGLDisplay display, EGLConfig* config, EGLSurfac
         attributeList[13] = EGL_PIXMAP_BIT;
         break;
     case GLContextEGL::WindowSurface:
-    case GLContextEGL::Surfaceless:
         attributeList[13] = EGL_WINDOW_BIT;
         break;
+    case GLContextEGL::Surfaceless:
+        attributeList[13] = EGL_STREAM_BIT_KHR;
+        break;
     }

     EGLint count;

January 29, 2024 06:00 AM