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

Updated Candidate Recommendation: CSS Values and Units Level…

Source: W3C's Cascading Style Sheets home page01 December 2022

1 Dec 2022 Updated Candidate Recommendation: CSS Values and Units Level 3.

Updated Working Draft: CSS View Transitions Level 1.

Source: W3C's Cascading Style Sheets home page24 November 2022

24 Nov 2022 Updated Working Draft: CSS View Transitions Level 1.

New Draft Note: CSS Snapshot 2022.

Source: W3C's Cascading Style Sheets home page22 November 2022

22 Nov 2022 New Draft Note: CSS Snapshot 2022.

Updated Candidate Recommendation Draft: CSS Display Level 3.

Source: W3C's Cascading Style Sheets home page18 November 2022

18 Nov 2022 Updated Candidate Recommendation Draft: CSS Display Level 3.

Minutes Telecon 2022-11-16

Source: CSS WG BlogDael Jackson • 17 November 2022

Full Meeting Minutes

Release Notes for Safari Technology Preview 158

Source: Surfin' Safari 16 November 2022

Safari Technology Preview Release 158 is now available for download for macOS Monterey 12.3 or later and macOS Ventura. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS Monterey, or System Settings under General → Software Update on macOS Ventura.

This release includes WebKit changes between: 255892@main…256138@main

Note: Shared Tab Groups and syncing for Tab Groups, Website Settings, and Web Extensions are not enabled in this release.

Web Inspector

CSS

Rendering

Media

JavaScript

WebCodecs

Web API

Updated Working Draft: Selectors Level 4.

Source: W3C's Cascading Style Sheets home page11 November 2022

11 Nov 2022 Updated Working Draft: Selectors Level 4.

Minutes Telecon 2022-11-09

Source: CSS WG BlogDael Jackson • 10 November 2022

Full Meeting Minutes

Release Notes for Safari Technology Preview 157

Source: Surfin' Safari 08 November 2022

Safari Technology Preview Release 157 is now available for download for macOS Monterey 12.3 or later and macOS Ventura. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS Monterey, or System Settings under General → Software Update on macOS Ventura.

This release includes WebKit changes between: 255077@main…255891@main

Note: Shared Tab Groups and syncing for Tab Groups, Website Settings, and Web Extensions are not enabled in this release.

Web Inspector

CSS

Rendering

JavaScript

WebCodecs

Web API

Media

Web Animations

HTML

Accessibility

Security

Privacy

Safari Web Extensions

WebDX: Improving the experience for web developers

Source: W3C Blog Dominique Hazaël-Massieux • 08 November 2022

When surveyed, 38% of developers in general seem to dread using Web technologies (HTML & CSS, JS in StackOverflow 2022 survey); and when asking Web developers and designers more specifically, 23% aren’t satisfied with the Web platform (MDN DNA 2020 survey). This could be worse – but how can we make it better?

As a development platform, the Web platform is fairly unique in being provided through competing browsers which implement a shared set of standardized technologies. This combination of cooperation in defining the technologies and competition in implementing them has long been recognized as an important driver of improvements for the platform as a whole, as implementers innovate on new user facing features and protections, improved developer tools, and increased performance.

While competing implementations are a great driver of innovation, it also creates fragmentation, a regular top pain point that developers report (e.g. browser compatibility pain point in MDN DNA survey 2020). What feature can developers rely on to ensure that their app will work on the combination of devices, operating systems and browsers that they need to serve?

Understanding and monitoring what constitutes the interoperable surface of the Web platform is a non-trivial task, especially as browsers now get updated on a very regular basis.

The Interop project is an ongoing effort to bring cooperation not just about the definition of technologies, but also about their deployment, with the clear goal of reducing fragmentation developers most suffer from.

Similarly, Open Web Docs provides home for cooperation in developing another key part of the developer experience, documentation, through contributions to MDN Web Docs.

To build on these positive patterns, the WebDX Community Group was launched a couple of weeks ago with a mission to facilitate coordinated approaches to improve the overall experience of developing for the Web platform. The group will initially focus on two key areas.

First, it will enable shared research on the pain points that developer face. Previous shared research efforts include the MDN Web Developer Need Assessment surveys that ran in 2019 and 2020. Their results unambiguously highlighted the cost of fragmentation for developers, and with additional complementary research, were key drivers of improvements in this space, in particular via the Interop project. The WebDX Community Group intends to provide a home to discuss topics and infrastructures for shared research on developer needs and wants. Our efforts start with a collaboration on short surveys that will run on a regular basis on MDN (with our deep gratitude to Mozilla and the MDN team). During W3C TPAC unconference in September, we also collected a number of other suggestions about how shared and curated research could help us take better decisions for the platform.

In complement to that, we want to provide structural improvements in how developers can understand and manage fragmentation: reducing fragmentation (as proposed by the Interop project) is the preferred approach, but some fragmentation is unavoidable (e.g. because hardware capabilities may differ across devices), and some of it is probably a necessary consequence of the competitive model of the platform.

We want to make it easier for developers to track the list of features that are widely available and those that are under development. My colleague and WebDX Community Group co-chair François Daoust developed an analysis of how features get described and their implementation tracked across a variety of tools and systems, including MDN Browser Compatibility Data and Can I Use that many developers already call upon to answer these questions. We believe that we can improve our approaches towards reducing fragmentation and making sure that developers know about it, provided that we can describe and agree on features that compose the Web platform.

It’s still early days! If you want to contribute and improve the developer experience of the most popular platform, please join the WebDX Community Group or bring your input to our GitHub repositories.

Minutes Telecon 2022-11-02

Source: CSS WG BlogDael Jackson • 03 November 2022

Full Meeting Minutes

Updated Candidate Recommendation Draft: CSS Box Model Level …

Source: W3C's Cascading Style Sheets home page03 November 2022

3 Nov 2022 Updated Candidate Recommendation Draft: CSS Box Model Level 3. Updated Working Draft: CSS Box Model Level 4.

Updated Candidate Recommendation Draft: CSS Color Level 4.

Source: W3C's Cascading Style Sheets home page01 November 2022

1 Nov 2022 Updated Candidate Recommendation Draft: CSS Color Level 4.

WebKit Features in Safari 16.1

Source: Surfin' Safari31 October 2022

Today, Safari 16 arrives for macOS Ventura and iPadOS 16. Numbered Safari 16.1, this release is also available for iOS 16, macOS Monterey, and macOS Big Sur.

To update to Safari 16.1 on macOS Monterey or macOS Big Sur, go to System Preferences → Software Update → More info. To update your Mac to macOS Ventura, go to System Settings → Software Update. To update to Safari 16.1 on iPad and iPhone, update iPadOS 16 and iOS 16 in Settings → General → Software Update.

Features that shipped in September’s Safari 16.0 include Container Queries, Subgrid, Web Inspector Extensions, Flexbox Inspector, Offset Path, Overscroll Behavior, Shared Workers, Shadow Realms, resolution media query, :has(:target), text-align-last, animation-composition, discrete animation, accessibility improvements for display: contents, improved VoiceOver performance, additional Apple Pay support, new Web Extension APIs, Manifest version 3 support, and much more. Safari 16.1 brings all of these features to iPadOS 16 and macOS Ventura.

Now let’s look at the new features and fixes arriving with Safari 16.1.

Web Push for macOS Ventura

a push notification on macOS

Safari 16.1 for macOS Ventura brings support for Web Push to Safari. Websites and web apps can now remotely send notifications using the same standards supported in other browsers — Push API and Notifications API, along with Service Workers — and deliver those notifications even when Safari isn’t running.

In Safari, users of your website or web app opt into notifications by first indicating interest through a user gesture — such as clicking a button. Then they’ll be prompted to give permission for your site or app to send notifications. Users can view and manage notifications in Notifications Center. And they can customize styles and turn notifications off per website in Notifications Settings.

If you’ve already implemented Web Push for your web app or website using industry best practices, it will automatically work in Safari. You do not need to be an Apple Developer Program member. However, if you’ve excluded Safari through browser detection, you’ll need to switch to feature detection to get it working. Web Push in Safari uses the same Apple Push Notification service that powers native push on all Apple devices. If you tightly manage push endpoints on your server, be sure to allow URLs from any subdomain of push.apple.com.

To learn more, watch the WWDC session Meet Web Push for Safari (15 min video), or read the article Meet Web Push on webkit.org.

Animated AVIF

Safari 16.0 brought support for AVIF still images to iOS 16. Safari 16.1 adds support for AVIF animated image sequences. Now both still and moving images saved in the AVIF format are supported on iOS 16, iPadOS 16, and macOS Ventura.

Passkeys

In September, iOS 16 introduced passkeys. Now with Safari 16.1, passkeys are supported everywhere Safari 16 is supported — including iPadOS 16, macOS Monterey, macOS Big Sur, and macOS Ventura, as well as iOS 16. Passkeys provide users with an incredibly easy way to log in, while delivering a profound increase in security.

The technology that makes passkeys possible is defined in open standards from the FIDO Alliance and the W3C, including the WebAuthn standard, which already has widespread support in browsers. Passkeys are an industry-wide effort, and “passkeys” is a common noun, to be used by anyone. You can offer passkeys alongside your existing authentication options. First, teach your backend to store public keys and issue authentication challenges. Then, on your website or web app, offer passkeys to users by adopting the APIs for creating new passkeys and allowing users to sign in with their passkey. If your website or web app already supports using a platform authenticator with WebAuthn, there are a few things to note as you add support for passkeys. Make sure you aren’t limiting signing in to the device that saved the passkey; that is, don’t use a cookie to “remember” that a user set up a key on a particular device. Also, make sure the username fields in your existing sign-in forms are compatible with AutoFill by adopting “conditional mediation”. Finally, start to refer to passkeys, and treat them as a primary way to sign in.

To learn more, watch the WWDC22 session, Meet Passkeys (27 min video) or read Supporting passkeys.

New viewport sizes on iPadOS

Three Safari browser windows, layered over one another, floating in space. One tall and very narrow. One medium and square. One bigger and wide.

iPadOS 16 introduces an entirely new multitasking experience with Stage Manager. This means browser windows on iPadOS can be resized to many different viewport sizes and aspect ratios. Responsive web design techniques, including the use of CSS media queries and container queries, are key. There’s never been a single “tablet size” for layout, and now that’s more true than ever.

Hover on iPadOS with Apple Pencil

The new iPad Pro supports hover with Apple Pencil. In web browsers, users see hover states for links, animations, and more. Hover on iPadOS is yet another example of how structuring code using feature detection, instead of device or UA detection, helps future-proof websites and web apps.

Scroll to Text Fragment

Safari 16.1 adds support for Scroll to Text Fragment, making it possible to include a text directive for finding a text fragment as part of a URL. When a user navigates to a URL that includes such a directive, the browser scrolls the text fragment into view and marks it with a persistent highlight.

Screen capture improvements

screenshot of dialog message asking Allow webkit.org to share your screen?

On macOS Ventura, Safari 16.1 adds support for capturing a specific Safari window with getDisplayMedia(). Calling getDisplayMedia in response to a user action will show the user a prompt asking for permission to allow the sharing of their screen or a specific window of an application, including Safari windows. The MediaStream provided by getDisplayMedia contains a video stream of the screen or window that can be recorded, or used as part of a WebRTC session.

And More

Safari 16.1 adds support for web-to-App Store advertising with SKAdNetwork. It also adds support for WebDriver Wheel input source and actions. Safari Web Inspector adds support for the color picker to pick a color from any pixel on the screen.

Fixes and Polish

Safari 16.1 also contains bug fixes and feature polish. Many of these fixes improve the Interop 2022 score for Safari. The test pass rate for Safari 16.1 is 93.3%. That’s calculated from 84.3 points of a possible 90. The remaining 10 points are joint “investigation projects”.

Accessibility

CSS

Forms

Media

Rendering

Security

Web API

Feedback

We love hearing from you. Send a tweet to @webkit, @jensimmons, or @jonathandavis to share your thoughts on Safari 16.1. If you run into any issues, we welcome your feedback on Safari UI, or your WebKit bug report about web technology 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 use the WebKit Feature Status page to watch for new information about the web features that interest you the most.

To learn more about what’s in Safari 16.1 for web developers, read the Safari 16.1 release notes.

Minutes Extended Telecon 2022-10-26

Source: CSS WG BlogDael Jackson • 29 October 2022

Publications

View Transitions

Nesting

Full Meeting Minutes Part I and Part II

New Working Draft: CSS View Transitions Level 1. New Working…

Source: W3C's Cascading Style Sheets home page25 October 2022

25 Oct 2022 New Working Draft: CSS View Transitions Level 1. New Working Draft: Scroll-linked Animations. Updated Recommendation: CSS Containment Level 1.

‘Do you really understand CSS radial-gradients?’ is an artic…

Source: W3C's Cascading Style Sheets home page24 October 2022

24 Oct 2022 ‘Do you really understand CSS radial-gradients?’ is an article by Patrick Brosset with an explanation of radial gradients.

WebKit Features in Safari 16.0

Source: Surfin' Safari21 October 2022

Today, we are excited to announce the release of Safari 16.0 for iOS 16, macOS Monterey and macOS Big Sur. This release contains quite a few new web technologies that web developers can use to make their sites and web apps even better.

To update to Safari 16.0 on macOS Monterey and macOS Big Sur, go to System Preferences → Software Update → More info. To update to Safari 16.0 on iOS, install iOS 16. Safari 16 for macOS Ventura and iPadOS 16 are coming this October, and will include Web Push on macOS Ventura.

a word cloud of everything that shipped in Safari this year, including what's in Safari 16

We announced many details about what’s in Safari 16 in our article, News from WWDC22: WebKit Features in Safari 16 Beta, and the WWDC22 session, What’s new in Safari and WebKit (32 min video). But that’s not all. In the months since WWDC, we’ve added even more.

New since Safari 16 Beta 1

Safari for iOS 16 includes support for still images compressed using the AVIF format. Developed by the Alliance for Open Media, AVIF is an alternative to image formats like JPEG, PNG, GIF, or WebP. It offers multiple color spaces, lossless and lossy compression, and more. Support for AVIF will also come to macOS Ventura and iPadOS in October.

WebKit now fully supports the resolution media query. This media query provides a way for web developers to conditionally apply CSS based on the pixel density of a screen. For example: @media (min-resolution: 326dpi) { }.

WebKit now supports text-align-last, a CSS property that sets how the last line of a text block is aligned. For instance, a paragraph could have text-align: center applied to most its lines, while the last line of that paragraph is aligned right with text-align-last: right.

The :has() pseudo-class in WebKit now supports :target. The CSS :target pseudo-class selects an element when that element has an id that matches a fragment in the URL. For example, if a user clicks on a link that takes them to example.com/#chapter2, and an element on that page has the ID #chapter2, then the :target pseudo-class will select that element. In Safari 16, :has(:target) opens up new possibilities when using URLs with fragments. For an in-depth look at :has, read Using :has() as a CSS Parent Selector and much more.

Passkeys

Safari on iOS 16 adds support for passkeys. They provide users with an incredibly easy way to log in, while delivering a profound increase in security.

To sign in with a passkey, fill in your username (or email, depending on the site) and tap the button. Your device authenticates that it’s you, and you’re in.

The technology that makes passkeys possible is defined in open standards from the FIDO Alliance and the W3C, including the WebAuthn standard, which already has widespread support in browsers. Passkeys are an industry-wide effort, and “passkeys” is a common noun, to be used by anyone. You can offer passkeys alongside your existing authentication options. First, teach your backend to store public keys and issue authentication challenges. Then, on your website or web app, offer passkeys to users by adopting the APIs for creating new passkeys and allowing users to sign in with their passkey.

If your website or web app already supports using a platform authenticator with WebAuthn, there are a few things to note as you add support for passkeys. Make sure you aren’t limiting signing in to the device that saved the passkey; that is, don’t use a cookie to “remember” that a user set up a key on a particular device. Also, make sure the username fields in your existing sign-in forms are compatible with AutoFill by adopting “conditional mediation”. Finally, start to refer to passkeys, and treat them as a primary way to sign in.

To learn more, watch the WWDC22 session, Meet Passkeys (27 min video) or read Supporting passkeys. In October, support for passkeys will come to macOS Monterey and macOS Big Sur, as well as macOS Ventura and iPadOS.

Apple Pay

Safari 16 adds Apple Pay support for Merchant Tokens, a more efficient way to support recurring payments, and support for multi-merchant payments, a way to pay multiple merchants of record in one transaction. Safari 16 also supports Order Tracking to enable merchants on the web to provide detailed order and shipping information in Wallet. Apple Pay can now be used in all WKWebView.

Web Inspector Extensions

Safari 16 brings support for Web Inspector Extensions, enabling you to enhance Safari’s built-in web developer tools. Download these extensions on macOS by going to Safari > Safari Extensions and looking for Web Inspector Extensions in the App Store. Search for developer tools from your favorite third-party developer services, test suites, and frameworks — including Angular DevTools, which recently announced support. If you’d like to learn how to make such extensions, watch the WWDC22 session, Create Safari Web Inspector Extensions (18 min video).

Safari 16 includes even more for Safari Web Extensions, including the ability to sync which extensions are enabled across iOS, iPadOS, and macOS. Safari 16 supports both manifest version 2 and manifest version 3. Watch What’s new in Safari Web Extensions from WWDC22 to learn about the differences, and how to upgrade your extension. Web Extensions in Safari 16 also add support for declarativeNetRequestWithHostAccess permission and browser.runtime.getFrameID.

Container Queries

Similar to Media Queries, Container Queries allow you to adjust the layout or styling of a particular item on your web page based on the size of its container rather than the size of the viewport. Safari 16 supports size queries and container query units. “Size queries” are what web developers imagine when they talk about Container Queries — the opportunity to write CSS that only applies if a container is a certain size. Container Query Units are similar to Viewport Units, but they specify a length relative to the dimensions of a query container instead of the viewport. These include cqw, cqh, cqi, cqb, cqmin, and cqmax.

Subgrid

CSS Grid revolutionized what’s possible in layout design on the web. Subgrid takes Grid to another level, providing an easy way to put grandchildren of a grid container on that grid. It makes it possible to line up items across complex layouts without being constrained by the HTML structure. And Safari’s Grid Inspector lets you turn on the overlays for as many grids as you want — which is especially helpful when coding subgrid.

Web Inspector

Following last year’s addition of Grid Inspector, Safari 16.0 adds Flexbox Inspector. It pairs perfectly with the addition of Alignment Editor in Safari 15.4.

a screenshot of the Flexbox Inspector in action, drawing lines around the container, around each item, and marking gaps and free spaceOverlays for Flexbox containers make it easier to visualize the effects your CSS.

Safari’s Flexbox Inspector visually distinguishes between excess free space and Flex gaps. It also shows the boundaries of items, revealing how they are distributed both on the main axis and the cross axis of your Flexbox containers. The toggleable “Order Numbers” option show the layout order of elements in the container, which can be helpful when using the order property. And just like our overlays for Grid last year, you can simultaneously show as many Flexbox overlays as you want, without any impact on scrolling performance. A single checkbox turns them all on.

In the Timelines Tab there are additional links to reference documentation, and a new experimental Screenshots timeline that captures screenshots of the viewport when content changes are painted.

The Elements Tab now supports showing Container Queries in the Styles sidebar.

The Sources Tab brings new improvements including allowing local overrides for requests to use regular expression matches in the redirect URL and local overrides for responses now being able to be mapped to a file on disk.

The Network Tab includes a new proxy indicator, and provides a way to entirely block network requests.

Accessibility Improvements

Safari 16 introduces a re-architecture of WebKit’s accessibility support on macOS. By adding Isolated Tree Mode, WebKit reduces VoiceOver hangs by offloading accessibility work to a secondary thread, improving performance and increasing responsiveness. This change allows WebKit to service more accessibility requests from clients like VoiceOver in less time than before. On some complex webpages, we’ve measured twice the number of accessibility requests served in twenty-five percent less time. Safari 16 also greatly improves accessibility support for elements with display:contents by ensuring they are properly represented in the accessibility tree.

Animation Improvements

WebKit now supports CSS Offset Path (also known as Motion Path), providing web developers the ability to animate objects along a custom path of any shape. The offset-path property lets you define a geometrical path along which to animate. The offset-anchor, offset-distance, offset-position, and offset-rotate properties give you additional abilities to refine the exact movement of the object being animated. While the offset property acts as a shorthand for combining these properties.

In Safari 16, you can now animate track sizes in CSS Grid, dynamically changing the size of rows and columns.

Safari 16 also adds support for composite operations, resolving how an element’s animation impacts its underlying property values. And it adds support for discrete animation to thirty-nine CSS properties.

Overscroll Behavior

CSS Overscroll Behavior determines what happens when a user scrolls and reaches the boundary of a scrolling area. It’s useful when you want to stop scroll chaining — when a user scrolls inside a box and hits the end, you now have control over stopping or allowing scrolling on the rest of the page.

Shared Workers

WebKit now supports Shared Workers. It’s similar to Service Workers, running JavaScript in the background, but its lifetime is slightly different. Your Shared Worker runs as long as the user has any tab open to your domain. All the tabs open to the same domain can share the same Shared Worker.

Additional Features

Safari 16 adds support for Shadow Realms, <form>.requestSubmit(), the showPicker() method for HTML input elements, and the worker-src Content Security Policy directive.

Fixes and Polish

Safari 16.0 also contains quite a few bug fixes and feature polish.

CSS

Forms

Security

WebGL 2

Web Inspector

Web Driver

Safari Web Extensions

Feedback

We love hearing from you. Send a tweet to @webkit, @jensimmons, or @jonathandavis to share your thoughts on Safari 16. If you run into any issues, we welcome your feedback on Safari UI, or your WebKit bug report about web technology 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 use the WebKit Feature Status page to watch for new information about the web features that interest you the most.

To learn more about what’s in Safari 16 for web developers, read the Safari 16 Release Notes.

Minutes Telecon 2022-10-19

Source: CSS WG BlogDael Jackson • 20 October 2022

Full Meeting Minutes

Release Notes for Safari Technology Preview 156

Source: Surfin' Safari 19 October 2022

Safari Technology Preview Release 156 is now available for download for macOS Monterey 12.3 or later and macOS Ventura beta. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS Monterey, or System Settings under General → Software Update on macOS Ventura.

This release includes WebKit changes between: 254352@main…255076@main

Note: Shared Tab Groups and syncing for Tab Groups, Website Settings, and Web Extensions are not enabled in this release.

Web Inspector

CSS

JavaScript

Rendering

Media

Web Animations

Accessibility

Web API

Safari Extensions

Bug Fixes

CSS Values and Units Level 4 WD Updated

Source: CSS WG Blogfantasai • 19 October 2022

The CSS Working Group has published an updated Working Draft of CSS Values and Units Level 4. This specification defines the CSS property definition grammar, and the value types that are common across many specs, such as <length> or <string>. We will also be posting a synchronized version of CSS Values and Units Level 3 shortly (as a CR, it needs to pass additional reviews).

Most changes since the last WD are largely error corrections and refinement of existing features, see full changes list. We also added a new section defining in generic terms the computation pattern for coordinating list-valued properties (like background-*), so that it can easily be referenced by other property sets (like animation-*). The remaining open issues are largely centered around two topics: clarifying url() handling and refining details of the viewport units and their interaction with the “initial containing block”.

With the draft in a largely-completed state, this is essentially the last call for wide review. See also the complete list of additions since Level 4.

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-values-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 Values and Units Level 4.

Source: W3C's Cascading Style Sheets home page19 October 2022

19 Oct 2022 Updated Working Draft: CSS Values and Units Level 4.

Minutes Telecon 2022-10-12

Source: CSS WG BlogDael Jackson • 12 October 2022

Full Meeting Minutes

Minutes Telecon 2022-10-05

Source: CSS WG BlogDael Jackson • 06 October 2022

Full Meeting Minutes

W3C DevMeetup report – Vancouver, 2022

Source: W3C Blog Marie-Claire Forgue • 06 October 2022

Visual for the W3C Developer meetup, organized by W3C Developer Relations team, on 13 Sept. 2022, in Vancouver, Canada. The graphics represents Vancouver's skyline at twilightOn September 13, 2022, in Vancouver BC, Canada, the W3C developer relations team organized a developer meetup as part of  the annual W3C TPAC2022 (Technical Plenary /  Advisory Committee) week for the global Web community to coordinate the development of Web standards.

Today, we are pleased to share the recorded videos of the four talks that were delivered during the event. They illustrate how W3C community paves the path of creating solid Web standards, from incubating an idea to a deployed standard that people can reliably use and adopt. Each of these videos come accompanied by their transcripts and the set of slides the speakers used:

This event was made possible thanks to the support of our sponsors, to which we want to express again our gratitude: Yubico, Igalia, Samsung Internet, FTG, WithYou and Legible.

Thank you to the W3C DevMeetup in Vancouver sponsors: Igalia, Samsung Internet, Yubico, FTG, Legible and WithYou

Follow us on @w3cdevs and subscribe to our YouTube channel to track new Web technology development, and to learn of opportunities to contribute to W3C work!

Release Notes for Safari Technology Preview 155

Source: Surfin' Safari 05 October 2022

Safari Technology Preview Release 155 is now available for download for macOS Monterey 12.3 or later and macOS Ventura beta. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS Monterey, or System Settings under General → Software Update on macOS Ventura.

This release includes WebKit changes between: 254352@main…254623@main

Note: Shared Tab Groups and syncing for Tab Groups, Website Settings, and Web Extensions are not enabled in this release.

Web Inspector

CSS

Rendering

JavaScript

Media

Scroll to Text Fragment

Web API

Loading

WebDriver

lessons on more inclusive conferences

Source: Web Directions Blog John • 30 September 2022

ID24 2022

This is my script for my recent presentation at ID24, the long running accessibility and inclusive design focussed conference.

I spoke on some of the lessons we’ve learned over the last 3 years or so developing our online conferences, and how these might also help make our in-person conferences more accessible and inclusive as well.

You can watch the presentation, or read on for the script.

Today I’ll share some of the lessons we’ve learned about designing more accessible and inclusive conferences

Do as I say…

I guess there’s a kind of irony that a lot of what I’ll talk about today is how live online conference presentations have a negative impact on accessibility and inclusion, and how we can address that by pre-recording presentations. And yet here I am presenting live.

Now I must admit when we first planned to move our conferences online in the wake of Covid, perhaps the single most daunting decision, which was ultimately, as I’ll talk about extensively, the best one we made, was whether we’d have presenters present live, or pre-record presentations.

Now, as I sit here quite stressed about whether the network will stay up, whether I’ll make a mistake, and myriad other factors that could go wrong, when I really should be focussing on the delivery, perhaps this live presentation will become the best advertisement for pre-recorded presentations that I advocate.

I will however record a version, using the technologies and techniques I mention throughout, to give a side by side comparison and let you be the judge.

I’ve also tried to minimise the visual aspects of this presentation, for reasons I hope will make sense as we go along.


A word or two about inclusion

A lot of the focus at ID24 this year as in every year is accessibility. And today I’ll be talking quite a bit about that–but I also want to address some issues around inclusion, and what role design, and intentional decision making can play in making events more inclusive–this includes things like the languages people comfortably speak or listen in, socio economic status, and where in the world someone lives.

About me, and Web Directions

Very briefly, mostly for context–My name is John Allsopp. I’m a middle aged man of european origin and my pronouns are he/him.

Since 2004 I’ve been involved in organising conferences for web designers, developers, and all sorts of adjacent areas of professional practice.

I’ve also spoken dozens if not hundreds of times at events around the world, in person and online.

Our programs have always had a considerable focus on assistive technologies and ways of designing and developing with accessibility in mind…

And we’d always tried to make our events what we believed were as accessible as possible.

The pandemic, as with many things, made us rethink that.


A return to 2019

Let’s start by going back pre-covid (if that’s possible), and thinking about what most people would have considered the essential, indeed sufficient features of an accessible conference.


We might have expected

And none of these really address a fundamental but overlooked challenge to accessibility that pretty much every presentation has–presentations are almost always strongly driven by _visuals_–text on slides, graphs, charts, animated gifs, memes, all things that are inaccessible to people with visual disabilities as this graph shows.

This slide intentionally left blank

Right now the screen actually reads “this slide intentionally left blank”. The “joke” is of course that there is no graph–but if you are a person with a visual disability and you suddenly heard a room full of people laugh at a visual joke like this (and think of how many presentations use memes and animated gifs) or once again hear a speaker say ‘as this graph shows’ hopefully you’ll start to get a sense of how much we take for granted as presenters that our audience can see our slides.

And we haven’t even started to consider disabilities outside hearing and sight–events, as do almost all spaces outside the home expect neuro distinct people to enter environments that can be distressing and overwhelming, with no accommodations that may reduce this distress, or aid in the ability to focus on and absorb the material.

Now, today for the most part I’m going to focus on online conferences, but these considerations also impact accessibility and inclusion for in-person presentations and events–though some of the accommodations I’ll be talking about are more challenging or perhaps even impossible to adopt in that context.


When Covid struck

As I mentioned, Since 2004 I’ve been running events for web and digital folks-designers, engineers, and product managers.

When Covid struck…

And a key aspect of this was seeing how online-first events and presentations could focus more on accessibility and inclusion.

Today I’d like to talk about some of the things we learned–which as I mentioned don’t just apply online, and which don’t just apply to conferences.

I then want to zoom (sorry, too soon?) in on a couple of specific things we did, some technology we built, to make our online conferences more accessible for Deaf people, and people with visual disabilities–but which also have benefits for all our users.


Conferences in 2019

OK, it’s now 2019 again. What does a conference look like? They probably are

Now, a small irony here is that the very first presentation at a conference I helped organise was a pre-recorded presentation from Jeffrey Zeldman–I don’t think we’ve had one since.

Anyway.

Then Covid made in person conferences impossible–for how long we simply had no idea.

We, and many conference organisers did the only thing that was available other than giving up altogether (which many many did)–we started planning to move our events online.


Just like [whatever] only online

Now, over the last 30 years or so we’ve seen so many things from the physical world move online. And there’s a very common pattern when that happens. The most immediate example is how web design initially, and for quite some years really, largely mimicked print design.

A perhaps a more pertinent example here is how shopping moved online.

Online shopping is of course commonplace now, and might look like ebay, or Shein, or a more traditional shopping site, but the earliest incarnations were literally malls–only online.

Now lost in the mists of time is World Avenue, a huge play by IBM in the mid 1990s to essentially create a digital simulacrum of a mall. They spent more than a hundred million dollars on it. Back when that was real money.

How did this effort go? Well so monumental a failure was this colossal, hugely hyped effort that a search will yield you perhaps a handful of references to World Avenue anywhere online, pretty much all of which are reports from when the service was shut down. There are no screenshots–it’s simply vanished.

This is a commonplace of moving activities from the real world online–we start by recreating as closely as possible the ‘real world’ experience “only online” (something which BTW most ‘metaverse’ implementations do–food for thought).


Online conferences post covid

And we saw this with many online conferences post covid


They were


What might a conference look like if it were online-first?

We wanted to avoid the world avenue approach to online events.

We wanted to rethink all of these factors and ask “What might, what could a conference look like if it were online-first?


The format

Let’s takes a look at something as straightforward as the format

Long back to back days

Long, back to back days are really limiting factors in so many ways–for audiences and organisers.

They limit attendance and so access (with an 8 hour day, you can really only target one time zone effectively–folks elsewhere need to get up early, or stay up late to attend. And allocating long stretches of time, over multiple days, is hard, and exhausting, especially when so much of work and life had moved onscreen).

So what did we do about that?


Replaced by short sessions

We had shorter sessions (originally around 4 hours, though they ended up shorter still), across originally 4 successive Fridays, then later 2 successive Fridays.

We were asking much less in terms of time and attention from our audience, for a similar amount of content.


Pre-recorded, not live presentations

We also importantly decided to pre-record all presentations. As I mentioned at the top, to be honest this of all the decisions we made at the time felt like the most risky–would attendees feel ripped off watching presentations that weren’t live?

Interestingly, only a few days ago Apple held their first in-person event, announcing new iPhones and so on, for 3 years.

While media and others assembled in the Steve Jobs theatre the entire event was pre-recorded! Asking media to fly across the country or the world to attend a prerecorded presentation even on new iPhones is something that would have been unimaginable 3 years ago.

Noted Apple watcher John ‘Daring Fireball’ Gruber observed

These pre-filmed product introductions move faster — the transitions between scenes happen at the speed of energetic cinema…

This allows Apple to cover the same amount of information in less time…

[it] allows Apple to use far more employees to make the presentation.

It’s also a win for would-be presenters who find speaking in front of a live audience too stressful.


More accessible and inclusive

Ultimately this decision to pre-record was the single best decision we made, not least because of the implications for access and inclusion.


For speakers

Let’s start with speakers.

As John Gruber observed, and many of us will know first hand, folks often find the idea of speaking in front of an audience very anxiety inducing. Pre-recording may make it more accessible for such folks to speak.

Speakers whose first language isn’t that of an event, even when proficient in that language, may find the idea of speaking publicly in a language other than their first challenging. Again, pre-recording may help address that.


For speakers

Trust me, conferences have limited travel budgets, and so the opportunities for speakers to travel to an event to speak are in short supply, and so tend to go to more established speakers. This restricts the opportunity for new, and more marginalised voice to be heard.

Speakers from many parts of the world may also be impacted by visas requirements–these may take months to receive, be arbitrary withheld, may require being without a passport for an extended period of time while being processed. And they are not inexpensive–at each in person event we pay thousands of dollars for visas for speakers to visit Australia.

Including speakers

All these things factors mean that certain voices and points of view are far less likely to be heard–non English speaking presenters, people from the global south, people with anxiety disorders, and other neuro-distinct people.

When we moved to an online, pre-recorded model, and provided equipment (or otherwise made it easy to record, for example by arranging a videographer), the opportunity for speakers whose first language wasn’t english, who lived in countries where you’re much less likely to traditionally see speakers from, increased enormously.

We have had numerous speakers whose first language isn’t English, and from right across the world–Nigeria, Kenya, Brazil, Argentina, Indonesia, Malaysia, the People’s Republic of China, and Palestine among many others we’d never had speakers from previously.

For attendees

For attendees, issues of access can similarly include cost (of tickets, and of travel) visa challenges, and also language barriers. But even when we move online and address some of these, there’s subtler challenges like time zones–An 8 hour long day will fit neatly into essentially one timezone. Those outside the time zone where the conference is being held might find themselves having to get up very early, or stay up late to attend, a challenge for folks with families, and other carer responsibilities among others.

But, by having shorter, pre-recorded sessions, we found we could repeat each session multiple times a day–ultimately 3 times across a 24 hour period. This meant more or less wherever someone was in the world, they could attend during their work hours (or of course if they were early risers or late night types they could attend then).

So, by rethinking the basic conference format, there can be tremendous wins in terms of inclusion across numerous factors.


Equity

One last thing on this before I turn to my main focus of today, was the issue of equity.

Developers in Malaysia earn on average less than 20% of a developer in a WEIRD (Western, educated, industrialized, rich and democratic) country. The same goes for developers in many countries around the world.

We wanted to ensure equitable access to our events, and so did quite a bit of research into relative developer salaries around the world.

We found there were more or less three tiers.

A top tier of markets like North America, Western Europe and Australia

A middle tier of about half that and then a Tier of about 1/6th of the top tier.

So we priced accordingly–using geolocation to price in local currencies adjusted to the relative developer earning power.

The impact of all these? We certainly ended up with attendees from around the world–still weighted toward attendees from the global north, but that’s likely as much about our ability to market globally as anything. But it was definitely gratifying to see folks from all over the world at these events.


Accessibility

But what I really want to focus on today is accessibility. While we’re seeing a return to in-person events, and I feel that we’ll see fewer and fewer online conferences that look and feel like conferences in the future, the job these conferences have been doing for their audiences will continue.

We’ll continue to see presentations online, as indeed we have for years–often recorded, in-person presentations thrown up on Youtube after a conference ends.

Hopefully some of what we’ve learned and implemented with our online events since 2020 might help these presentations become more accessible than they currently typically are.

So let’s start there, with the accessibility, or otherwise, of online presentations.


Deaf and hard of hearing attendees

Increasingly, at least for deaf and hard of hearing audiences, we see accommodations being made, even for live presentations like today’s.

A great many presentations end up on youtube, and auto-captioning has been a thing there for some time. It’s quick, and free.

And it is certainly better than nothing. You’re experiencing it right now.

But particularly with specialist topics, and above all for presentations focussed on software development, where code is used and referred to a lot, automatic, or even non expert human created captioning comes up very short. Terms of art, and code examples are often bafflingly mistranscribed.

For speakers with even a moderate accent (including possibly folks like Aussies), or people who speak quickly, auto-captioning is often not particularly accurate.

This is where a pre-recorded approach brought additional benefits in terms of accessibility.

Pre-recording gives us time to carefully edit transcripts and captions, to ensure, for example, programming language features, terms of art and less commonly used terms are properly transcribed.


Captions and neurodiversity

While we think of captions as being an accommodation for the Deaf and hard of hearing, folks with ADHD and on the autism spectrum talk about the benefits of captioning for being able to focus (possibly with the sound turned down to minimise distraction).

And we’re not all in quiet calm environments, with noise cancelling headphones.

So captions are an accommodation that benefit not simply Deaf and hard of hearing viewers. Or even just people with disabilities.


Live Transcripts

But we went one step further than simply captioning. We also created what we call a live transcript,


Onscreen right now is a screen recording of our live transcript feature–a block of text shown with the presentation video. What the speaker is saying at that time is highlighted, but several lines before and after the current phrase, are also visible.

A caption is what is being said right at that moment, and once displayed is no longer available. Our transcripts provide context–they allow the viewer to glance back and understand the context of what they are listening to now. But with what is being said right now highlighted, and easy to return to.

Remember, our sessions last for 3 or more hours, and concentrating consistently for such long periods (we do provide some downtime during the day) is challenging for anyone, and perhaps particularly so for some neuro distinct viewers.

We’ve had viewers praise these transcripts for how they allow them to focus better, and not lose track of during presentations.


Visuals in presentations are deeply inaccessible

But, as I also alluded to earlier, we rarely talk about the very visual nature of presentations and how inaccessible these can be for folks with visual disability.

How much of the information, context, even the subtlety and humour of a presentation is on a slide–and slides are completely inaccessible–they have no Accessibility Object Model–they are just bits on a screen. Screenreaders and other assistive devices can’t read them, let alone describe the meme GIF used, or the graph “that you can see here”.

So we decided to try and do something about that.


Audio Descriptions?

We originally considered audio-descriptions, where a narrator describes what’s on screen, as a solution to this.

AD is commonly used for film and TV, and even live theatre. We spoke with AD experts about the feasibility of using Audio Descriptions for presentations, but the conclusion we came to with them was this would likely be very distracting (in essence, the audio description runs as a second audio stream alongside the main stream) and technically very challenging.

So we approached this in a different way.


Accessible Slides

We take every slide from every presentation (another reason why pre-recording is really valuable, this is otherwise not only impracticable, it’s impossible).

We mark it up semantically in HTML (headings, lists, links and so on), and we provide alternate descriptions for purely visual elements like graphs, images and other visual components.


We time stamp these for when the slide appears in the presentation.

There is an option at our conference site for these to be displayed during the presentation, synchronised to the presentation.

On the screen right now is an example from a recent conference. On the left is the ode of the prevention. To its right are the accessible slides. As a slide appears in the presentation, the HTML version moves into view and is highlighted.


ARIA Live Regions

But how does this help people with visual disability? They are afterall still text on a screen.

Well, the slides are presented in an ARIA Live region. This means that screen readers which support live regions recognize and will read out slides as they appear on screen.

We talked about not opting for audio descriptions, as we felt they would be distracting.

So what’s the difference here?

With AD, the only control a user has is whether they are on or off. There’s no speed control, no skipping, no choice of voice, or volume.

With our ARIA based approach, the user of a screen reader is in control of all these aspects of how, and whether, slides are read to them, using their assistive technology of choice.

Not not only that–all the text, including code examples, of a presentation are now text on screen-that can be copied and pasted.

Links can now be activated

Each inaccessible black box slide of a presentation is now essentially a web page.

We often talk about how accessibility accommodations aren’t solely beneficial for people with disability, but this is a very powerful example.

And it doesn’t stop with with the live presentations

When a presentation is available on demand after a conference, the slides now serve as ways into the content–you can read through the slides then jump straight into the starting point of that slide.

And similarly with transcripts.

There’s no need to watch an entire presentation–read through and jump in to the points of interest.

And the entire text of the presentation is accessible to search engines.

The technical details

So, how’s this done?

For the developers in the audience I’d like to take just a short while to look at how it is done under the hood.

I mentioned live regions. These are an ARIA feature that

“are perceivable regions of a web page that are typically updated as a result of an external event when user focus may be elsewhere”. “Since these asynchronous areas are expected to update outside the user’s area of focus, assistive technologies such as screen readers have either been unaware of their existence or unable to process them for the user.”


<div aria-live="polite" aria-atomic="true">
<h3>So can pop-ups...</h3>
</div>

Onscreen we have the markup for our accessible slides. There’s a div with two attributes–aria-live=”polite” aria-atomic=”true”. Inside is heading of level 3 with the text ‘So can popups’ and then we close the div.

Thats it. All you need. We have a little JavaScript that updates the content of this div with the content of the slide each time that slide appears on screen. And because we’ve let assistive devices know this is a live region, screen readers will read out the new text inside the element.

We have this separate element that we update the contents of with the text of the current slide, because live regions are only read out when the content of the region changes.

We add the aria attribute aria-live to make the element a live region, and the value ‘polite’ to tell assistive devices how assertive or otherwise it should be in reading out the content when that changes (there are three levels–off, polite and assertive).

Our second aria attribute, atomic, specifies that the whole of the element should be read out when the content changes, not just the changed content–this is because each slide is entirely different.


With live regions, screen readers can read out changes to the region–So in our case the text of a slide when it is updated. All under the control of the user, who may choose to turn them off, the speed and voice with which they are read, when to skip them–whatever options their technology provides the user.

Here it is in action–with Voice over on Mac OS reading the live region. You’ll see in the utility window the text of the live region, and how as the slide below updates, Voice Over starts reading this.

My instinct, not as a user of screen reader technology, is the value might be more for on-demand videos where the user might pause the video, have the slide read out, then resume the video, than simultaneously with the presentation. But importantly, the user is on control of their experience.


Real world use

Btw, this system is one we’ve used extensively for our own events since 2020, and has been used by OZEWAI, the long running Australian Web Adaptability Initiative for their inaugural online conference, and by AITCAP, and Accessible & Inclusive Tourism Conference for their two online conferences to date.

While the technology is not yet open sourced, it’s our intention, and should you be interested in using it, please get in touch–we’re very glad to help make that happen!

If you’d like to see the technology in action, please visit our streaming service, Conffab, which features coming up on 1000 presentations from past conferences of our and other organisers. A free account will get you access to anything over 2 years old and many of those presentations (as well as all of our newer ones) feature the technologies I’ve been talking about today.


Bonus thoughts

As we have a little more time, here are some bonus, sort of random thoughts I’ve come to attending, hosting, and speaking at conferences for many years now.


Use a script

I’m increasingly of the opinion that scripted presentations, particularly for online presentations, are much preferable to extemporaneous ones, even for presentations that are highly structured. I’ve edited the transcripts of hundred of presentations and to be honest almost every unscripted presentation is essentially gibberish–full of discursions, repetitions, half finished sentences–which we tend not to notice when someone is on stage but is far more noticeable in a screen based presentation–it’s also a barrier to inclusion for folks whose first language isn’t that of the presentation, and potentially neurodistinct people who might find a discursive presentations that goes off on tangents, and so on, difficult to keep track of.

I’m not saying that you necessarily read every word, but there’s a reason why very little television, even live television is impromptu.


Don’t live code

The ID24 notes to speakers discouraged live coding. This is something I strongly agree with–not least from from the perspective of accessibility

Again having edited the transcript of many live coded sessions, and sat through many more, they are almost invariably disjointed, halting, the speaker being focussed on the code, and what inevitably seems to go wrong, the audience focussed on what might have gone wrong.

Onscreen code examples are typically tiny and unreadable. And yet also rely on people seeing what the presenter is coding. Frankly, I would ban live coding (don’t @ me)

Great presentations, I think, are about the what and why–there’s little time in most presentations for the how–leave that for workshops and tutorials.


Be sparing with screen recordings

Once again I’ve broken my own rule here–I used screen recordings to show some of our accessibility features in action.

Adding alternative or descriptive text for images, charts, graphs and the like, while time consuming, is still beneficial. I’ve found adding alternative text for screen recordings to be very challenging, and speakers rarely describe in detail what they are demonstrating with a screen recording–so at the very least when using a screen recording describe for those who cannot see the recording what is happening.


Get in touch & thanks!

@johnallsopp on twitter and so forth
experience the technology [conffab.com]

If you’d like to see the technology in action, please visit our streaming service, conffab, which features coming up on 1000 presentations from past conferences of our and other organisers. A free account will get you access to anything over 2 years old and many of those presentations (as well as all of our newer ones) feature the technologies I’ve been talking about today.

If you’re keen to talk more, agree or disagree, or might be interested in using the technology we’ve developed (it is built with vanilla JavaScript CSS and HTML, with no dependencies on frameworks or libraries) please get in touch.

I’m @johnallsopp on twitter and elsewhere, and john@webdirections.org if you’d like to email

Thanks to the ID24 crew for putting together this amazing event–I’ve run many in person and online and I can’t begin to imagine even attempting an event like this, let alone pulling it off year after year!

Enjoy the rest of ID24!

The post lessons on more inclusive conferences appeared first on Web Directions.

Front end engineering at Web Directions Summit

Source: Web Directions Blog John • 29 September 2022

From the very beginning, Web Directions events have at their heart been about developing for the Web.

For years before we ran our first conference, that’s what I did–not only building many sites, but writing books, articles, online courses, software for developers–and we’ve continued to focus on the technologies and practices of building great web sites apps, experiences ever since.

At Web Directions Summit in 2022, for the first time ever, we have not just one but two front end focussed tracks–officially we’re calling them the Front End Engineering and React Ecosystem tracks, but you might also find it useful to think about them in the terms Brad Frost coined a couple of years ago, the front-of-the-front-end and back-of-the-front-end tracks. As Brad puts the difference succinctly

a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.

Brad Frost, front-of-the-front-end and back-of-the-front-end web development

And as captured in this illustration from an article by Chris Coyier discussing the concept, “The Great Divide

different types of developer represented by line illustrations. On the left a female appearing person wearing glasses. Above them is the text The Great Divide, Chris Coyier, CSS Tricks

Now of course many front end developers, perhaps most, don’t exclusively focus on just one or the other of these, and so, at our conferences it’s always possible to set your own agenda–we’ve designed the program so it’s easy to move from one track to the other talk by talk or session by session.

But what about the sessions you have to miss? No worries, all the conference sessions are available on demand soon after the conference ends!

So whether your primary focus is front-of-the-front or back-of-the-front, we’ve got you covered.

Check out the amazing lineup today–for front of the front, or back of the front, and we’ll hopefully see you in Sydney December 1 and 2.

Can’t get to Sydney? Concerns about meeting in person?

If you can’t get to Sydney, or have concerns about meeting in person at this moment, we’ve got you covered–with a streaming option. And it’s not just a stream of the conference sessions–there’ll be chat to allow you to connect with other attendees, online and in person, and you’ll be able to ask questions of the speakers as well. We’ve spent a lot of time thinking about delivering the best possible online conference experience the last 3 years or so, and we’ll bring that to bear in the conference experience, all hosted on our very own streaming platform Conffab.

The post Front end engineering at Web Directions Summit appeared first on Web Directions.

Minutes Telecon 2022-09-28

Source: CSS WG BlogDael Jackson • 28 September 2022

Full Meeting Minutes

Closing a 30 pixel gap between native and web

Source: Microsoft Edge Blog Microsoft Edge Team • 27 September 2022

We talk a lot about Progressive Web Apps (PWA) in the context of mobile devices, but they have an enormous potential on desktop operating systems that's only beginning to materialize. Recently, with many new web capabilities in the Chromium browser engine and UX changes in Microsoft Edge and on Windows, installed desktop web apps are really starting to look and feel like native apps. One remaining gap in how web apps appear on desktop is their ability to create their own title bar experiences. While native apps have been able to display content anywhere in the app window, including in the title bar, installed web apps have been forced to go with the default experience, making them visually different. Two screenshots of VSCode. The first is VSCode as a native app, showing that the app can display its own custom content in the title bar. The second is VSCode as a web app, showing that the entire top area is reserved for the default title bar. We're excited to announce the availability of a new PWA feature that closes this gap and helps blur the line between apps and websites even more. The Window Controls Overlay feature gives web apps the ability to use the full surface area of the app window to display their own content, including where the default title bar is normally displayed. Only the system critical window buttons remain and are displayed as an overlay on top of the web content. Even if the title bar is about 30 pixels high only, the design implications of having access to the area it normally occupies are huge. What can we do with just 30 pixels? Display a custom title, a menu bar, some account information, navigation tabs? Look at other desktop apps you use, and you'll quickly realize that they all make use of this area in some way. And now, installed web apps can too! An illustration of a web app window, showing that the the app can display its content over the entire surface area of the window, except where the window control buttons appear. We worked on this feature as part of our contributions in the Web Capabilities project (aka Project Fugu), in collaboration with other browser makers and tech companies. This project aims to make it possible to build all types of apps using web technologies, and to push the barriers for what's possible on the web today. We proposed the Window Controls Overlay feature as an explainer in January 2020, then built the early implementation in Chromium, made it available as an Origin Trial, and published a formal specification. We're now releasing the Window Controls Overlay feature as a default experience for all to use in Microsoft Edge 105.

Learn to use the Window Controls Overlay

To learn to use the feature, check out the technical documentation as well as the MDN reference docs. You might also be interested in these A List Apart and web.dev tutorials. These resources go into much more detail than we will see in this article. Here, we’ll quickly go over the 3 most important building blocks of Window Controls Overlay:

Opt-in to the feature with your Manifest

PWAs need a Web App Manifest to be installable, and many PWA features are declared in the Manifest file. The Window Controls Overlay is no exception. To opt-in to this feature use the display_override manifest member and set its value to [“window-controls-overlay”]. Here is a code snippet showing this:
{
  "name": "App name",
  "description": "App description",
  "lang": "en-US",
  "start_url": "/",
  "theme_color": "#ffffff",
  "background_color": "#ffffff",
  "display_override": [
    "window-controls-overlay"
  ]
}
On the surface, this is the only required change to start making use of the title bar area. However, the feature also comes with new CSS environment variables and a JavaScript API which both help make sure you deliver an experience that works well across devices and operating systems.

Adapt to the environment with the titlebar-area-* CSS variables

Once the app uses the Window Controls Overlay feature, its web content is displayed over the entire window surface, and the control buttons act as an overlay. To avoid displaying content below these buttons the new titlebar-area-x/y/width/height variables can be used in the env() CSS function. They give you the geometry of the area that the title bar would have occupied next to the control buttons if it was displayed. Because this area can be different on Mac, Windows, and Linux, having access to browser-provided variables helps create a layout that works everywhere. As shown below, the title bar area is different on Windows (and Linux) and macOS. An illustration showing 2 windows, one on Windows or Linux and the other on macOS. The location of the title bar area is highlighted in both. The following code snippet shows how these variables can be used to position a fixed header element in the title bar area:
header {
  position: fixed;
  left: env(titlebar-area-x, 0);
  top: env(titlebar-area-y, 0);
  width: env(titlebar-area-width, 100%);
  height: env(titlebar-area-height, 30px);
}
Since the env() function supports fallback values (the second parameter in the function), this snippet will work even when the Window Controls Overlay feature isn’t being used, such as when the web app is displayed in a browser window.

Detect when changes occur with the navigator.windowControlsOverlay API

In addition to the CSS environment variables, you can use the new navigator.windowControlsOverlay API to know the coordinates of the title bar area from JavaScript and detect when they change. This can be helpful to re-arrange the web content displayed in this area as the app window size changes, or when the user opts-out of the Window Controls Overlay feature. In the following code example, we listen to geometry changes and apply a class on the body element if the width of the title bar area is smaller than 250px.
if (navigator.windowControlsOverlay) {
  navigator.windowControlsOverlay.addEventListener('geometrychange', () => {
    const { width } = navigator.windowControlsOverlay.getTitlebarAreaRect();
    document.body.classList.toggle('narrow', width < 250);
  });
}
Note how we first test if the API exists, which helps ensure the app works in browsers that don’t support the feature. You can also use the navigator.windowControlsOverlay.visible boolean to know if the overlay is visible (i.e. if the default title bar is hidden) and the navigator.windowControlsOverlay.getTitlebarAreaRect() method to get its geometry. We believe PWAs are a great fit for making desktop web applications. Turning your website into an app that really feels like it belongs on desktop has never been so easy and using the Window Controls Overlay feature will help you create desktop apps that look much more modern and engaging to your users. We hope it is useful to you, and can’t wait to see what you build!

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