# WebKit WebKit is an open-source web content engine for browsers and other applications. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Squarespace & Web Standards: How We Helped Bring HTML Video & Audio Lazy Loading to Today's Browsers DevFeed: [Squarespace & Web Standards: How We Helped Bring HTML Video & Audio Lazy Loading to Today's Browsers]() Original publisher: [Read original article]() Author: Scott Jehl Published: 2026-03-30T21:00:00Z Content type: article Language: en Sources: [Squarespace](), [Squarespace Engineering Blog]() Topics: [web-standards](), [lazy loading](), [HTML](), [Web platform](), [WebKit](), [Chromium](), [Google Chrome](), [Firefox]() Tags: [browsers](), [chrome](), [chromium](), [firefox](), [html](), [lazy-loading](), [standards](), [web-standards]() ### AI overview Squarespace engineers describe how they helped add lazy loading for HTML video and audio to the HTML Standard. They contributed proposed implementations for Firefox and WebKit, worked with Chromium developers on a Google Chrome implementation, and added automated testing. ### Source excerpt At Squarespace, many of our core products are built on web standards, and our engineers are constantly pushing the boundaries of the web's capabilities. Occasionally, those boundaries reveal a limitation: an opportunity for the web's native capabilities to grow. This post is the story of how we found such an opportunity to work with the standards community to improve the web in a way that we - and everyone who uses it - can benefit. ## SwiftUI Custom URL Schemes DevFeed: [SwiftUI Custom URL Schemes]() Original publisher: [Read original article]() Author: Keith Harrison Published: 2025-10-27T11:26:47Z Content type: tutorial Language: en Sources: [K. Harrison]() Topics: [SwiftUI](), [WebView](), [iOS](), [WebKit](), [App]() Tags: [async](), [auto-layout](), [configuration](), [how-to](), [ios](), [ios-26](), [objective-c](), [protocol](), [scheme](), [swift](), [swiftui](), [web](), [webview](), [wwdc](), [xcode]() ### AI overview This tutorial explains how to create a custom URL scheme handler for SwiftUI WebViews in iOS 26. It covers implementing URLSchemeHandler, loading local HTML resources from an app bundle, registering the handler in a WebPage configuration, and displaying the page in a WebView. ### Source excerpt Create a custom URL scheme handler for SwiftUI WebViews. Custom URL schemes Apple introduced both WebView and WebPage SwiftUI views in iOS 26. These provide similar WebKit functionality to the UIKit WKWebView APIs. This includes being able to register custom URL schemes to load local resources. Suppose I have an App that loads quotations from the local App bundle. My URL scheme uses the format: quotes://001.html There are a few steps to support a custom URL scheme: Create a custom URL scheme handler that knows how to load the local resources. Register the scheme handler in a WebPage configuration. Have the WebView load and display the web page. Let's look at each of those steps. URLSchemeHandler (iOS 26) The URLSchemeHandler is a protocol with a reply method to return an async sequence of results. The AsyncSequence expects us to either yield a URLResponse and some data or throw an error. struct QuoteSchemeHandler: URLSchemeHandler { static let scheme = "quotes" func reply(for request: URLRequest) -> some AsyncSequence< URLSchemeTaskResult, any Error > { AsyncThrowingStream { continuation in ... } } } The reply method provides us with the URLRequest. I start by extracting the URL and checking it matches our quotes scheme: guard let url = request.url else { continuation.finish(throwing: QuoteError.missingURL) return } guard url.scheme == QuoteSchemeHandler.scheme else { continuation.finish(throwing: QuoteError.invalidScheme) return } To construct the URL response I need the mime type and length of the data. I first extract the filename from the URL, determine the mime type from the file extension, and then load the data: do { let file = try filename(for: url) let mimeType = try mimeType(for: file) let data = try Data(contentsOf: file) I can then build the URLResponse: let response = URLResponse( url: url, mimeType: mimeType, expectedContentLength: data.count, textEncodingName: "utf-8" ) If nothing has gone wrong I then add the response and the data to the AsyncSequenc ## CSS random() DevFeed: [CSS random()]() Original publisher: [Read original article]() Author: Erik Runyon Published: 2025-10-08T00:00:00Z Content type: article Language: en Sources: [Erik Runyon]() Topics: [CSS](), [WebKit](), [Front end](), [JavaScript]() Tags: [css](), [frontend](), [javascript](), [safari](), [web-development]() ### AI overview The article examines Safari's non-standard CSS random() function, describing its random(min, max, step) syntax and current limitations. It explains that the function supports numeric and color contexts but not selectors or string values, and discusses possible uses such as random dimensions, collection items, images, and displayed random numbers. ### Source excerpt Safari recently implemented a non-standard (yet?) CSS random() function (currently only in WebKit, and not yet part of any CSS specification). Since many recent CSS features are directly aimed at replacing common JavaScript functionality, I expected this function to do the same. While it has some neat use cases, it doesn't cover most of the scenarios where I currently use JavaScript's Math.random(). What it does The basic format of the function follows the pattern "random(min, max, step)". For instance, if you want to assign an element a random height between 50px and 200px, you would use "height: random(50px, 200px)". You can also include a "step" value like so "height: random(50px, 200px, 50px)" where the values will always be a multiple of 50. You can see more examples on the WebKit post "Rolling the Dice with CSS random()" and Frontend Masters "Very Early Playing with random() in CSS". What it doesn't Currently, random() can only be used in numeric or color contexts -- not in selectors or string values like URLs or text content. I have two primary use cases, and one just for fun. All three are marked-up as I would expect to use them if they were supported in the CodePen below. Random items from a collection A common pattern on many Notre Dame sites would be to show a random item from a collection. These could be content such as faculty spotlights, recent publications, or student profiles. We always know how many we're choosing from, and they're always contained to a specific section. So being able to use CSS to show a random child using ":nth-child" would be fantastic. Random images Less common is showing random images. This could be in a feature area on the homepage, or even a decorative background image. This would require the ability to concatenate a string with the random number. Random numbers A "just for fun" feature would be displaying the value from the random() function. My initial thought would be a CSS only dice roller. The demo in the pen would requir ## Apple's WebKit Feature Pace and Browser Competition on iOS DevFeed: [Apple's WebKit Feature Pace and Browser Competition on iOS]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-09-23T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [WebKit](), [browsers](), [iOS](), [Web]() Tags: [apple](), [browsers](), [features](), [standards](), [web](), [webdev]() ### AI overview This opinion article examines Apple's approach to web-platform collaboration and feature development, arguing that WebKit has trailed Blink and Gecko while Apple's iOS policies prevent competing browsers from shipping alternative engines. It introduces data intended to assess claims about Apple's handling of challenging APIs. ### Source excerpt Update: The charts below were inappropriately snapped, compressing the range of values. This has been corrected. Feature availability numbers also changed since drafting and have been updated. In several recent posts, I've attempted to address how the structure of standards bodies and their adjacent incubation venues accelerates or suppresses the potential of the web as a platform. The pace of progress matters because platforms are competitions, and actors that prevent expansions of basic capabilities risk consigning the web to the dustbin. Inside that framework, there is much to argue over regarding the relative merits of specific features and evolutionary directions. This is healthy and natural. We should openly discuss features and their risks, try to prevent bad consequences, and work to mend what breaks. This competitive process has made browsers incredibly safe and powerful for 30 years. Until iOS, that is. Imagine my surprise upon hearing that Apple isn't attempting to freeze the web in amber, preserving advantages for its proprietary platform, and that it instead offers to redesign proposals it disagrees with. Contents Background Is Apple Engaged In Constructive API Redesign? General Trends Hard Cases Overall Impressions What's Happening Here? As I have occasionally documented, this has not been my experience. I have relatively broad exposure to the patterns of Apple's collaboration, having designed, advised on, or led teams that built dozens of features across disparate areas of the platform since the Blink fork.1 But perhaps this was the wrong slice from which to judge? I've been hearing of Apple's openness to collaboration on challenging APIs so often that either my priors are invalid, or something else is at work. To find out, I needed data. Background A specific parry gets deployed whenever WebKit's sluggish feature pace comes up: "controversial" features "lack consensus" or "are not standards" or "have privacy and security problems" (unspecified). The ## Safari 16.4 Adds Long-Delayed Web Platform Features DevFeed: [Safari 16.4 Adds Long-Delayed Web Platform Features]() Original publisher: [Read original article]() Author: Alex Russell Published: 2023-02-22T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [WebKit](), [browsers](), [Web platform](), [PWA]() Tags: [browsers](), [competition](), [components](), [compression](), [css](), [pwa](), [reporting](), [safari](), [wasm](), [webdev](), [webrtc]() ### AI overview This commentary reviews Safari 16.4's web-platform additions, including PWA, Web Components, CSS, Web Codecs, WASM SIMD, compression, reporting, Canvas, and WebRTC changes. It argues that many features arrived years after Chromium implementations and notes some improvements remain limited to macOS and iPadOS. ### Source excerpt If you're a web developer not living under a rock, you probably saw last week's big Safari 16.4 reveal. There's much to cheer, but we need to talk about why this mega-release is happening now, and what it means for the future. Contents WebKit's Roaring Twenties Good Things Come In Sixes What Changed? Headcount Is Destiny Early Innings But first, the list! WebKit's Roaring Twenties Apple's summary combines dozens of minor fixes with several big-ticket items. Here's an overview of the most notable features, prefixed with the year they shipped in Chromium: 2015: Web Push for iOS (but only for installed PWAs) 2020: PWA Badging API (for unread counts) and id support (making updates smoother) 2015: PWA installation for third-party browsers (but not to parity with "Smart Banners") A bevy of Web Components features, many of which Apple had held up in standards bodies for years1, including: 2019: Constructable Stylesheets (important for performance) 2019: Form participation and default ARIA role 2021: Declarative Shadow DOM for "SSR" Myriad small CSS improvements and animation fixes, but also: 2018: CSS Typed OM for faster styling from JavaScript 2020: CSS Custom Properties can now be animated 2019: