The future of style

The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.

Latest articles

Implementing Vertical Form Controls

Source: Surfin' Safari 18 March 2024

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

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.

Minutes Telecon 2024-03-13

Source: CSS WG BlogDael Jackson • 14 March 2024

Full Meeting Minutes

Minutes Anchor Positioning Breakout 2024-03-13

Source: CSS WG Blog Dael Jackson • 14 March 2024

Full Meeting Minutes

Updated Working Draft: CSS Anchor Positioning.

Source: W3C's Cascading Style Sheets home page14 March 2024

14 Mar 2024 Updated Working Draft: CSS Anchor Positioning.

Updated Working Draft: CSS Values and Units Level 4.

Source: W3C's Cascading Style Sheets home page12 March 2024

12 Mar 2024 Updated Working Draft: CSS Values and Units Level 4.

Contributing to Speedometer 3.0: Capturing real-world challenges on the web

Source: Microsoft Edge Blog Microsoft Edge Team • 11 March 2024

In collaboration with cross-industry browser vendors under the Speedometer governance policy, the Microsoft Edge team is very excited to have contributed to the recently released version 3.0 of Speedometer, as announced on browserbench.org. First released in 2014, Speedometer is a popular browser benchmark and a key driver of recent browser performance improvements. Version 3.0 has several improvements to the test runner and adds many new tests over version 2.1. An important goal was to capture common, present-day challenges faced by developers by incorporating new variants, frameworks, and modern usage scenarios to the Speedometer tests. The Microsoft Edge Team contributed a new Complex DOM set of tests to meet these goals. Our aim was to represent the scalability challenges faced by modern web applications, and to drive performance improvements for these applications across the ecosystem.

Motivation: The challenge for modern web applications

Over the past few years, the Edge team collaborated with several Microsoft web application teams to provide expert recommendations for addressing scalability and performance issues. We did this by delving deep into performance profiles, application software stacks, and architecture. These investigations have consistently shown that the complexity of the DOM and CSS rules is an important driver of end-user perceived latency. Inefficient patterns, often encouraged by popular frameworks, have exacerbated the problem, creating new performance cliffs within modern web applications. The new Complex DOM tests perform DOM mutations in the context of a large DOM tree, which trigger a cascade of costly CSS selector matching operations and style recalculations. To facilitate the real-world representation of the Complex DOM tests, the Edge team took a data-driven approach to collect more data on DOM sizes and CSS selectors.

DOM sizes – How large is large?

The table below lists some data on DOM tree sizes and their maximum depth in familiar web pages and web application interfaces. We also got inputs on DOM sizes from Adobe in some of their web applications, recognizing the need to capture the performance challenges in the presence of large DOM trees. This gave us a good idea of the DOM tree sizes that would surface rendering performance issues in a benchmark test.
Webpage DOM size Max depth
amazon.com 3746 22
youtube.com 9082 30
Google results page 3458 48
reddit.com 4460 21
MDN Promises article 4167 17
walmart.com 3382 25
Facebook (after scrolling) 9957 63
Gmail (opened email) 3494 69
HBO Max 5478 19
Airbnb.com (login and open filters) 3388 38
Adobe Photoshop (Quick Actions panel) 6751 ≥ 24
Adobe Photoshop (Text Box new) 6331 ≥ 31
bbc.com/news/world 3898 26
nationalgeographic.com 4111 23
Google docs 3558 15
Google sheets 5730 18
Stack overflow post 2521 19
Microsoft Outlook 2870 32
Microsoft Teams 2542 32
apple.com/apple-vision-pro 2857 18
Twitter 2488 59
timesofindia.indiatimes.com 2789 22

CSS selectors – How complex is complex?

Complex CSS selectors are composed by combining several simple selectors using combinators like the descendant, child, adjacent and the sibling combinators. They cause browsers to perform complex matching operations and costly style recalculations. For more details about CSS selector performance, see The truth about CSS selector performance. The Edge team collected data on CSS selectors that occur in real-world web applications, pointing us to CSS selectors that challenge application performance. A few representative ones are listed below. Microsoft Outlook: Microsoft Teams: Examples from other Microsoft apps: While the performance challenges posed by complex CSS selectors are widely observable, they manifest differently when they are used in conjunction with other CSS properties or technologies like Web Components.

Variations of the Complex DOM framework

For technologies like Web Components that support Shadow DOMs (an encapsulation mechanism for isolating parts of a DOM tree from the code effects of one another), performance challenges can come from Constructable stylesheets, CSS variables, and fallbacks. We customized the Complex DOM framework for the Web Components and LIT based implementations to surface these challenges. We also provided two flavors of the Complex DOM framework, one that nests a sizeable chunk of the DOM tree within a CSS stacking context and another that does not as this impacts the rendering order of HTML elements in a DOM tree, which in turn impacts performance in large web applications.

The Complex DOM test

The Complex DOM test is based on a complex application shell, which embeds the TodoMVC application, as shown in the image below: The Complex DOM test webpage in a browser window. The key idea is to perform the simple and seemingly isolated actions of the TodoMVC application, such as adding, checking or deleting items, within the broader context of a large and complex web application. This simulates the scalability challenges observed when end users interact with real-world web applications. The application shell used in the Complex DOM test is fashioned after a generic productivity application to have a real-world look-and-feel, leveraging Adobe's Spectrum CSS library in its implementation. It consists of a scrollable sidebar element that embeds a large DOM tree, several complex CSS selectors (around 70), and a realistic ribbon menu – totaling to a little more than 6000 DOM elements.

Representing a large DOM structure

The Edge team collaborated internally with Microsoft's Tensile team to build the Complex DOM application shell, borrowing heavily from their parametrized DOM tree generator. The Tensile framework is designed with the goal of representing the (realistic) costs incurred during page load, style recalculation, layout, and paint by real-world web applications. Early data indicates that it is an accurate predictor of overall performance for applications with complex CSS and large DOMs. In a case study shipping the Persona control in Fluent, the Tensile framework reported a 30% performance improvement in scripting and styling across two versions of the Persona control implementation which is reflective of the 24% improvement observed in an actual application using the control. The ribbon contains about 469 descendent elements, and provides drop-down popover menus, for seven relevant and realistic operations. Two of the sample popovers, reminder and backlog, are shown in the images below: The reminder popup of the Complex DOM test web page The backlog popup of the Complex DOM test web page

Representing complex CSS selectors

The complex DOM application shell consists of about 70 CSS selectors which are constructed by composing them with up to six simple selectors. Some selectors style todo list elements while others style the popovers in the ribbon. They are designed such that all of them either fully match or partially match a todo list element. A partial match is when a sub selector matches a DOM element, but the entire selector does not. This ensures that the Complex DOM shell captures the performance issues caused by both matching and partially matching CSS selectors to well represent real-world user interactions in complex stateful situations. For example, consider the following two selectors: The first selector matches an element in the todo list whereas the second selector does not because no todo list element has the .high-priority class. However, a todo element would partially match the rightmost portion of the selector, i.e., :checked ~ label.

Try it out!

We are eager for you to check out Speedometer 3.0. We think that the collaboration between cross-industry browser vendors has been very effective in capturing real-world challenges on the web in browser benchmarks like Speedometer. We look forward to continuing this collaboration and making the web more performant for you all! Feedback, comments, new ideas and suggestions for improvements are very welcome! Please send them to the Speedometer GitHub repository. – Luis Fernando Pardo Sixtos, Issack John, Sean Monahan, Sulekha Kulkarni, Leo Lee, Alex Russell

Speedometer 3.0: The Best Way Yet to Measure Browser Performance

Source: Surfin' Safari 11 March 2024

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.

Updated Candidate Recommendation Draft: CSS Backgrounds and …

Source: W3C's Cascading Style Sheets home page11 March 2024

11 Mar 2024 Updated Candidate Recommendation Draft: CSS Backgrounds and Borders Level 3.

Release Notes for Safari Technology Preview 190

Source: Surfin' Safari 10 March 2024

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

CSS

New Features

Resolved Issues

History

Resolved Issues

HTML

New Features

JavaScript

Resolved Issues

Media

Resolved Issues

Deprecations

Networking

Resolved Issues

Rendering

Resolved Issues

SVG

New Features

Resolved Issues

URLs

Resolved Issues

Web API

Resolved Issues

Web Inspector

Deprecations

An HTML Switch Control

Source: Surfin' Safari08 March 2024

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’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.

Minutes Anchor Positioning Breakout 2024-03-06

Source: CSS WG Blog Dael Jackson • 08 March 2024

Full Meeting Minutes

Minutes Telecon 2024-03-06

Source: CSS WG Blog Dael Jackson • 08 March 2024

Full Meeting Minutes

WebKit Features in Safari 17.4

Source: Surfin' Safari 08 March 2024

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

Browser Changes

CSS

Forms

Fullscreen

HTML

JavaScript

Loading

Lockdown Mode

Media

Rendering

Safari Extensions

Scrolling

Storage

SVG

URLs

Web Animations

Web API

Web Inspector

WebGL

WebKit

WebRTC

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.

Minutes Telecon 2024-02-28

Source: CSS WG BlogDael Jackson • 29 February 2024

Full Meeting Minutes

Updated Working Draft: CSS Color Level 5.

Source: W3C's Cascading Style Sheets home page29 February 2024

29 Feb 2024 Updated Working Draft: CSS Color Level 5.

Release Notes for Safari Technology Preview 189

Source: Surfin' Safari 22 February 2024

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

Resolved Issues

Deprecations

HTML

Resolved Issues

JavaScript

Resolved Issues

Rendering

Resolved Issues

SVG

Resolved Issues

Web API

Resolved Issues

Deprecations

Web Inspector

New Features

Resolved Issues

WebAuthn

Resolved Issues

WebGL

New Features

WebRTC

New Features

Resolved Issues

CSS Text 4 Draft Updated

Source: CSS WG BlogFlorian Rivoal • 19 February 2024

The CSS Working Group has published an updated Working Draft of CSS Text 4. This CSS module defines properties for text manipulation and specifies their processing model. It covers line breaking, justification and alignment, white space handling, and text transformation.

This is a fairly minor update, mostly focused on refinements to the text-spacing-trim property, which should be of interest for CJK typography. Changes since the last Working Draft are listed in the Changes section.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-text-4]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Updated Working Draft: CSS Text Level 4.

Source: W3C's Cascading Style Sheets home page19 February 2024

19 Feb 2024 Updated Working Draft: CSS Text Level 4.

Updated Candidate Recommendation Draft: CSS Color Level 4.

Source: W3C's Cascading Style Sheets home page13 February 2024

13 Feb 2024 Updated Candidate Recommendation Draft: CSS Color Level 4.

Minutes Telecon 2024-02-07

Source: CSS WG BlogDael Jackson • 08 February 2024

Full Meeting Minutes

Release Notes for Safari Technology Preview 188

Source: Surfin' Safari 07 February 2024

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

Resolved Issues

Animations

Resolved Issues

Browser Changes

Resolved Issues

CSS

New Features

Resolved Issues

Deprecations

Forms

Resolved Issues

Loading

Resolved Issues

Lockdown Mode

Resolved Issues

Media

Resolved Issues

Rendering

Resolved Issues

Scrolling

Resolved Issues

Storage

Resolved Issues

Deprecations

SVG

Resolved Issues

Web API

New Features

Resolved Issues

Deprecations

Web Extensions

Resolved Issues

WebAuthn

Resolved Issues

WebGL

New Features

Resolved Issues

WebRTC

Resolved Issues

Updated Working Draft: CSS Fonts Level 5.

Source: W3C's Cascading Style Sheets home page06 February 2024

6 Feb 2024 Updated Working Draft: CSS Fonts Level 5.

The web just gets better with Interop 2024

Source: Surfin' Safari 02 February 2024

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?

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.

Microsoft Edge and Interop 2024

Source: Microsoft Edge Blog Microsoft Edge Team • 01 February 2024

Microsoft Edge is pleased to, once again, join Apple, Mozilla, Google, Bocoup, and Igalia in announcing the launch of Interop 2024. This is a continuation of a multi-year cross-organization project which acknowledges web developer pain points and aims at making the web platform more pleasant to work with. We're doing this by implementing frequently requested features and fixing the top cross-browser compatibility issues. Since its inception with the Compat 2021 effort, and then with the Interop 2022 and Interop 2023 efforts, the project brought about a number of improvements to the web platform. This year again, we're working on another set of features and compatibility fixes that will help with your day-to-day web development tasks.

Layout

It's fair to say that Flexbox and Grid have revolutionized the way we create layouts on the web and removed the need for other complex or less responsive techniques. To make these features work as best as they can, we, together with our Interop partners, have worked every year since 2021 on reducing the number of browser inconsistencies when using Flexbox and Grid. But some minor differences persist and we're making this an Interop focus area again this year. While we're on the topic of CSS layout, did you know that Subgrid is now supported across all major browsers? Firefox and Safari both implemented it in 2022, and Microsoft contributed support for it in Chromium in 2023, making Subgrid available in Chrome, Edge, and other Chromium-based browsers.

CSS architecture

The way we write and organize our CSS code has changed a lot recently. Thanks to the Interop project, building blocks like Cascade Layers, the :has() pseudo-class, and Container Queries are now interoperable across browsers, and make it possible to write more concise and clearer code that also adapts better to your users' devices. This year, we're continuing to improve in this area by turning our attention to CSS nesting. CSS nesting helps make code more readable, modular, and shorter by making it possible to nest child CSS rules in parent CSS rules. While CSS nesting is supported already, we want to ensure that it works in the exact same way across all browsers.

HTML elements

The dialog HTML element is great. It makes it possible to easily work with dialog boxes in a webpage without making your code more complex and having to re-implement focus handling and accessibility. It was first introduced in Chrome and was later part of the Interop 2022 project. It's now possible to use the dialog element in all browsers. This year, the Interop project sets its focus on a related HTML feature, one that will also make a lot of complicated code unneeded: the Popover API. With the Popover API, you can display content above other content without it being a z-index nightmare, without being cut off by the overflow behavior of a parent element, and without needing JavaScript code. The API is available in Chromium-based browsers, Safari, and as a preview in Firefox. This year, the Interop project is focusing on making the Popover API work the same across implementations. At Microsoft, we're very excited about this and especially about the positive impact it will have on the upcoming customizable <select> element, a feature we've originally prototyped.

Other focus areas

On top of the above highlights, here is the full list of Interop 2024 focus areas: If you want to see even more details about each area and follow our progress, check out the Interop 2024 Dashboard. We're excited to be part of the Interop project again this year and look forward to the improvements to the web platform. More importantly, we look forward to the great web experiences you all will be able to build with these additional cross-browser features.

Internationalization (I18N) leadership change and goals for the future

Source: W3C Blog Coralie Mercier • 01 February 2024

Photo of flags of the world by Vladislav Klapin on Unsplash

At the end of 2023 W3C staff members Richard Ishida and Fuqiao Xue were running the internationalization work of the Consortium. When Richard transitioned to semi-retirement on 1 January, 2024, Fuqiao Xue took over the role of Internationalization Lead, and is now the contact point for all internationalization related activity at W3C. Richard has reduced his time commitment, and will focus largely on the aspects of the work related to Language Enablement.

Internationalization is making the World Wide Web worldwide. The Web needs to work for anyone who speaks any language or writes in any script.
Internationalization is designing content, applications, technologies and specifications in a manner that they can be adapted to all languages and writing systems. It makes it possible for people throughout the world to use the Web in their own language and feel natural about it. I18N isn't translations and localization although it sets up the architecture to provide them. It is really a design paradigm. One that sets out to deliver the promise that the Web breaks down geographical barriers.
Internationalization is about communication. It counters the digital divide, fosters digital economy and individual development, it promotes cultural understanding, inclusivity. I18N is one of the pillars of the Web for All.

Richard joined the W3C Team in 2002 with a background in translation and interpreting, computational linguistics, translation tools, and global user interface design. He had become involved in Internationalization by learning various languages -- French, then Spanish, Italian, German, Russian, and Japanese, choosing languages with the aim of communicating with a large proportion of the earth’s inhabitants. Coming from Xerox, where he received a corporate award for the Xerox product development process, Richard provided services and training in international design and localizability of user interfaces and documents. Over the years at W3C, Richard introduced outreach activities to the internationalization work, and then went on to develop, in phases, a robust gap-analysis framework to document and figure out which specific issues need fixing. The framework can be applied to all the languages we are investigating. Gap-analysis documents describe gaps, give them a priority, and point to specifications, tests, etc. This is complemented by a suite of GitHub issue lists, an issue tracker page, and a notification system that sends one email a day to subscribers related to their area of interest, and contains links to issues that have changed in the framework repositories, or those of CSS, HTML, or other W3C working groups. This allows individuals who use the Web like you and me to easily and quickly contribute. This is what Richard wants to achieve: language enablement.

To appreciate the place it holds within Internationalization work at W3C, you need to understand that three axes are critical to achieving progress in making the World Wide Web truly worldwide:

  1. Language enablement is a framework through which gaps are identified relating to how well languages or writing systems are supported on the Web. The gaps are then mapped out as areas to fix or typographic features to support so more languages win more shares of the Web, thus enabling participation by more people.
  2. Developer support enables the creation of standards and applications that support a global Web. It consists of advice and guidelines or focus projects that help other W3C groups, notably best practices for spec developers. Review of all specifications produced by other W3C groups is done as part of this to make sure they work for all around the globe.
  3. Education and outreach helps people create content in their own language, or create content that will be localized. It includes an online validator, test suites, and the creation and dissemination of educational materials to help authors, developers and users understand and use I18N features.

Watch Richard present "Making the World Wide Web worldwide" in a 15 minute video. Then see the W3C standards and drafts tagged with I18N.

Fuqiao Xue joined the W3C Team in 2017 and the first project he worked on was CLReq, which set out to document requirements for Simplified and Traditional Chinese, and discussed Chinese layout requirements with a number of technologists and linguists from Mainland China, Taiwan, Singapore, and other regions. The work is still ongoing but the results are documented as an evergreen document. Interested in languages and writing systems since childhood, Fuqiao learned more and more about Internationalization and began to understand its importance. Fuqiao wants more experts, both technical and linguistic, to get involved and help us ensure that the Web meets local needs around the world.

"Languages are more than just a means of communication," said Fuqiao Xue. "They are vessels of culture, carrying with them traditions, stories, knowledge, and ways of understanding the world that have been passed down through generations."

Like Web accessibility, Internationalization needs to be built from day one because it can be very expensive and time consuming to retrofit. It's also good to develop in more than one language at a time to do it well and thoroughly. We're familiar with the notion that there are costs to non-conformance, but there are also opportunities in further breaking the language barriers. The best one is bridging the digital divide within and between countries. Another is leveling the playing field of market dominance. As internet penetration and digital literacy increase in regions like Asia and Africa, non-English content and platforms will gain prominence. 2024 is the 30th year of the Internet in China. Thanks to Internet penetration, there's been an increase in netizens and speed, as well as the emergence of non-English markets. Consider that of all the country levels, the .cn domain has the most domain names registrations.

To conclude, Internationalization of the Web is where communication meets emerging technologies and platforms, and where people all over the world connect. The scope of work is immense and the potential is exciting. To produce the change we want to our Web, we need people like you to step up to participate and work through the issues.

Minutes Telecon 2024-01-31

Source: CSS WG BlogDael Jackson • 01 February 2024

Full Meeting Minutes

Updated Working Draft: CSS Fonts Level 4.

Source: W3C's Cascading Style Sheets home page01 February 2024

1 Feb 2024 Updated Working Draft: CSS Fonts Level 4.

Minutes Telecon 2024-01-24

Source: CSS WG BlogDael Jackson • 25 January 2024

Full Meeting Minutes

Updated Working Draft: CSS Generated Content for Paged Media…

Source: W3C's Cascading Style Sheets home page25 January 2024

25 Jan 2024 Updated Working Draft: CSS Generated Content for Paged Media. Updated Working Draft: CSS Viewport Level 1.

WebKit Features in Safari 17.3

Source: Surfin' Safari 22 January 2024

Last month, Safari 17.2 brought our biggest December release of web technology ever — with 39 new features and 169 bug fixes. Now, in January, Safari 17.3 brings bits of polish to that release.

Fixes

CSS

Loading

Media

Privacy

Web Animations

Updating to Safari 17.3

Safari 17.3 is available for iOS 17, iPadOS 17, macOS Sonoma, macOS Ventura and macOS Monterey.

If you are running macOS Ventura or macOS Monterey, you can update Safari by itself by going to Software Update, and clicking “More info”. On macOS Ventura, that’s  > System Settings > General > Software Update > More info.

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

Feedback

We love hearing from you. To share your thoughts on Safari 17.3, find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. Or send a reply on X to @webkit. 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 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.3 release notes.

Feeds

The Future of Style features:

If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.

fantasai

Made with CSS! Valid CSS!Valid HTML 4.0! RSS feed Atom feed