Robert Nyman on web.dev

Submit your proposals for Interop 2024

2023-09-14T00:00:00Z

Over the past two years the Chrome team has successfully worked with our partners to improve the interoperability of the web. For Interop 2022 all major browser vendors and other stakeholders worked together to improve top browser compatibility issues identified by web developers. We repeated the process with Interop 2023, which still has a few months to run yet is already seeing a huge improvement in scores. For Interop 2023, we also requested public proposals for features to include, which led to many great suggestions representing the needs of the wider web ecosystem.

January 2023.

September 2023.

It's been a huge success, with many features reaching interoperability, and we're happy to announce that Interop 2024 is happening.

The first step is to gather suggested features, once again including ideas from the wider community, so the Interop 2024 proposal process is now open for submissions. Suggestions can include features that behave differently across browsers, or features that are not yet implemented in all browsers. Keep in mind that proposals with high quality specifications and web platform tests are more likely to be included, as this project is about reaching interoperability rather than specifying new features. The proposal submission process ends October 5, 2023.

Once the proposal period ends, the collected submissions will be discussed by browser vendors and other partners to determine the final list. It's likely that there will be more proposals than can be achieved during 2024, so some high quality proposals may not be selected. We are looking forward to reviewing all the submissions, and we'll post the final list here once Interop 2024 gets underway.

Submit your proposals here.

Interop 2023: continuing to improve the web for developers

2023-02-01T00:00:00Z

In 2023, all major browser vendors and other stakeholders are again working together to solve the top browser compatibility issues. The effort started on this scale with Interop 2022, and you can learn what we achieved together in the end-of-year post. Everyone involved believes this will help improve the experience for web developers everywhere. This year, for the first time, we publicly announced the proposal process and got many great suggestions from frameworks, large companies, browser vendors, and developers everywhere.

The Interop 2023 focus areas #

This time around, we have no less than 26 focus areas, outlined in detail in our project document. They are, in alphabetical order:

Border Image in CSS
Color Spaces and Functions in CSS
Container Queries in CSS
Containment in CSS
CSS Pseudo-classes
Custom Properties in CSS
Flexbox
Font feature detection and palettes
Forms
Grid
:has()
Inert
Masking in CSS
Math Functions in CSS
Media Queries
Modules in Web Workers
Motion Path in CSS Animations
Offscreen Canvas
Pointer and mouse Events
URL
Web Compat 2023: A catchall focus area for small bugs that cause known site compatibility issues
Web Codecs (video)
Web Components

You can find full details of all focus areas at Web Platform Tests based on MDN Web Docs, however here are a few that we think you might be really excited about.

Container Queries #

Container queries has been a top request from developers for many years, and in 2022 Chrome and Safari shipped it. Firefox expects to ship container queries in Firefox 110, and the tests for this focus area help to ensure that container queries work reliably cross-browser and according to the spec.

:has(…) #

Developers have for a long time asked for a parent selector in CSS. The :has() pseudo-class makes possible many of the use cases for parent selectors, as well as selecting a previous sibling element with respect to a reference element. For example, this makes it possible to style a figure that has a caption differently to one that doesn’t. Learn more about the use cases for has() in :has(), the family selector.

Custom Properties #

CSS custom properties, also known as CSS variables, make it possible to define a value once in a stylesheet and reuse that in many places, reducing repetition. For example, you can define a common color or font size once in a stylesheet and use this across components. Basic support for custom properties has been in browsers for a long time. Interop 2023 focuses on the @property at-rule. @property represents a custom property registration in a stylesheet, allowing for property type checking, setting default values, and whether the property should inherit values. Learn more in @property: giving superpowers to CSS variables.

CSS masking #

CSS masking provides methods to apply image effects, such as you might see in a graphics application, using CSS. Support for the various masking properties is patchy, making masking harder to use than it should be. This focus area will help developers to confidently use creative effects cross-browser. Learn more about applying effects to images in this article about image masking.

OffscreenCanvas #

The <canvas> element and Canvas API provide a scriptable way to draw graphics to the screen. However, this can cause performance problems as the work is completed on the same thread as user interaction. OffscreenCanvas offers developers a canvas which is decoupled from the DOM and the Canvas API. Developers can also run rendering tasks in a Web Worker, separate from the main thread. Learn more about the performance benefits of OffscreenCanvas.

Pointer and mouse events #

Pointer events are fired when interacting with a page using a mouse, pen, stylus, or touch screen. Mouse events are fired when using a mouse, but for historical reasons also for touch. This focus area covers the behavior of pointer and mouse interaction with pages, including how they interact with hit testing and scrolling areas. The focus area for 2023 excludes touch and stylus, due to a lack of Web Platform Tests in this area.

WebCodecs #

The WebCodecs API provides methods for developers to access the individual frames of video, and chunks of audio. It offers access to codecs that are already available in the browser, and various interfaces to interact with them. The article Video processing with WebCodecs shows how to use the API to decode and render individual frames to a canvas.

Web Components #

Web Components is an umbrella term for a number of technologies used to create reusable components, such as Custom Elements and Shadow DOM. Interop 2023 will focus on improving the interoperability of these foundational technologies.

Dashboard #

Follow progress throughout the year on the Interop 2023 dashboard, where you can see current scores and the status of addressing these focus areas across all major browser engines.

The Interop 2023 Dashboard (screenshot taken January 31st, 2023).

The Focus Area scores are calculated based on test pass rates. If you have feedback or want to contribute improvements to WPT, please file an issue to request updating the set of tests used for scoring.

All the Active Focus Areas and their overall Interop Score.

More about Interop 2023 #

Submit your proposals for Interop 2023

2022-09-21T00:00:00Z

The Chrome team has worked with other browser vendors and partners in the ecosystem to help improve browser compatibility since 2019, starting with the MDN Developer Needs Assessment survey and most recently on Interop 2022. For Interop 2022, all major browser vendors and other stakeholders worked together to improve top browser compatibility issues identified by web developers. We are thrilled at the progress that we’ve made together and are excited to announce Interop 2023 is happening!

March 2022.

September 2022.

The Interop 2023 proposal process is now open for submissions. Suggestions can include features that behave differently across browsers, or features that are not yet implemented in all browsers. Keep in mind that proposals with high quality specifications and web platform tests are more likely to be included, as this project is about reaching interoperability rather than specifying new features. The proposal submission process ends October 15, 2022.

Once the proposal period ends, the collected submissions will be discussed by browser vendors and other partners to determine the final list. It’s likely that there will be more proposals than can be achieved during 2023, so some high quality proposals may not be selected. We are looking forward to reviewing all the submissions, and we’ll post the final list here once Interop 2023 gets underway.

Interop 2022: browsers working together to improve the web for developers

2022-03-03T00:00:00Z

For the first time ever, all major browser vendors, and other stakeholders, have come together to solve the top browsers compatibility issues identified by web developers. Interop 2022 will improve the experience of developing for the web in 15 key areas. In this article, find out how we got here, what the project focuses on, how success will be measured, and how you can track progress.

It all started in 2019 #

Back in 2019 Mozilla, Google, and others started a major effort to understand developers' pain points, in the form of the MDN Developer Needs Assessment surveys, and the deep-dive Browser Compatibility Report. These reports gave us detailed and actionable information to address top challenges for developers with the web platform, and led to the Compat 2021 effort.

Among other things, Compat 2021 led to creating a solid foundation for powerful features such as CSS grid (12% usage and steadily growing) and CSS flexbox (77% usage), including the gap property in flexbox, which solves a top pain point for developers when adopting new layout methods.

We were delighted to reach a score of over 90% across all implementations at the end of 2021!

What is Interop 2022? #

Interop 2022 is a benchmark, agreed on by representatives of three major browser implementations, and developed through a process of public nomination and review with input from supporters Apple, Bocoup, Google, Igalia, Microsoft, and Mozilla.

The benchmark focuses on 15 areas, identified by developers as being particularly troublesome when they are missing or have compatibility issues across browsers. All browser vendors have agreed to focus on these areas, and everyone involved is excited to get started on making the experience of developing for the web measurably better.

The 15 areas of focus #

The following features will be the focus of Interop 2022. They include 10 new areas, plus 5 carried over from Compat 2021. The new areas of focus are:

Cascade layers #

Cascade layers give web developers more control over the cascade. They provide a way to group selectors into layers, each with its own specificity. This means you don't need to order selectors carefully or create highly specific selectors to overwrite base CSS rules.

Color spaces and CSS color functions #

To use color functions in a design system, you currently need to rely on Sass, PostCSS, or calc() on HSL values. Color functions built into CSS mean that colors can be dynamically updated, and new color spaces remove the restriction to the sRGB gamut, and perceptual limitations of HSL.

There are two functions defined in CSS Color Level 5 that enable more dynamic theming on the web platform:

color-mix(): Takes two colors and returns the result of mixing them in a specified color space by a specified amount.
color-contrast(): Selects from a list of colors the color with the highest contrast to a specified single color.

These functions support expanded color spaces (LAB, LCH, and P3), and in addition to HSL and sRGB, they default to the uniform LCH color space.

New viewport units #

Difficulties dealing with viewport sizing are prominent in both the MDN Browser Compatibility Report 2020 and the new State of CSS 2021 survey. CSS Values and Units Level 4 adds new units for the largest, smallest, and dynamic viewport sizes, lv*, sv*, and dv*. These units will make it easier to create layouts that fill the visible viewport on mobile devices while taking the address bar into account.

Additionally, the cross vendor team behind Interop 2022 will collaborate on researching and improving the state of interoperability of existing viewport measurement features, including the existing vh unit.

Scrolling #

The 2021 Scroll Survey Report confirms that scrolling features and scrolling compatibility are difficult to implement and have many areas for improvement. We'll focus on scroll snap, scroll-behavior, and overscroll-behavior to help scrolling be more consistent and smooth across platforms.

We are also exploring new scroll snap feature proposals.

Subgrid #

The subgrid value of grid-template-columns and grid-template-rows means that a grid item that has display: grid applied can inherit the track definition from the part of the parent grid it is placed over.

For example, the following three card components have a header and footer aligned with the adjacent card headers and footers, even though each card has an independent grid. This pattern works because each card is an item that spans three rows of the parent grid, then uses subgrid to inherit those rows into the card.

See this on CodePen.

Also included #

CSS Containment (the contain property)
The <dialog> element
Form controls
Typography and Encodings: including font-variant-alternates, font-variant-position, the ic unit, and CJK text encodings
Web Compat, which focuses on differences between browsers that have caused site compatibility issues affecting end users

The following areas made great progress through the Compat 2021 project, but there is still room for improvement. Therefore, they have been included in Interop 2022, in order that the remaining issues can be addressed.

Aspect Ratio
Flexbox
Grid
Sticky Positioning
Transforms

Investigation efforts #

In addition to the 15 focus areas, Interop 2022 includes three investigation efforts. These are areas that are problematic and need improvement, but where the current state of the specifications or tests aren’t yet good enough to be able to score progress using test results:

Editing, contenteditable and execCommand
Pointer and Mouse Events
Viewport Measurement

Browser vendors and other stakeholders will collaborate on improving the tests and specifications for these areas, so that they could be included in future iterations of this effort.

Measuring success and tracking progress #

The existing web-platform-tests dashboard will be used to track the progress in the 15 focus areas. For each area, a set of tests have been identified. Browsers are then scored against these tests, giving a score for each area and an overall score for all 15 areas.

To follow along and track the progress, check out the Interop 2022 dashboard. Over the course of the year, you can follow along and see how the platform you build for is improving.

See all browser scores per focus area on wpt.fyi/interop-2022.

What will all this mean for developers? #

The goal of these multi-year interoperability efforts, in the form of Compat 2021, Interop 2022 and much more, is to fully acknowledge and address the pain points developers have experienced through for many years. And it's not a one-browser effort but rather a strong collaboration between all major browser vendors and friends for improving the web platform across the board.

In essence, the goal is to make the web platform more usable and reliable for developers, so that they can spend more time building great web experiences instead of working around browser inconsistencies.

Let us know what you think #

If you have feedback on the improvements made during Compat 2021, or on any of the features included in Interop 2022, we would love to hear from you. Which of these features will make the most difference to your work? What are you really excited about? File issues for the GitHub repo or let us know on Twitter.

More about Interop 2022 from:

Compat 2021: Eliminating five top compatibility pain points on the web

2021-03-22T00:00:00Z

Google is working with other browser vendors and industry partners to fix the top five browser compatibility pain points for web developers. The areas of focus are CSS flexbox, CSS Grid, position: sticky, aspect-ratio, and CSS transforms. Check out How you can contribute and follow along to learn how to get involved.

Background #

Compatibility on the web has always been a big challenge for developers. In the last couple of years, Google and other partners, including Mozilla and Microsoft, have set out to learn more about the top pain points for web developers, to drive our work and prioritization to make the situation better. This project is connected to Google's Developer Satisfaction (DevSAT) work, and it started on a larger scale with the creation of the MDN DNA (Developer Needs Assessment) surveys in 2019 and 2020, and a deep-dive research effort presented in the MDN Browser Compatibility Report 2020. Additional research has been done in various channels, such as the State of CSS and State of JS surveys.

The goal in 2021 is to eliminate browser compatibility problems in five key focus areas so developers can confidently build on them as reliable foundations. This effort is called #Compat 2021.

Choosing what to focus on #

While there are browser compatibility issues in basically all of the web platform, the focus of this project is on a small number of the most problematic areas which can be made significantly better, thus removing them as top issues for developers.

The compatibility project uses multiple criteria influencing which areas to prioritize, and some are:

Feature usage. For example, flexbox is used in 75% of all page views, and adoption is growing strongly in HTTP Archive.
Number of bugs (in Chromium, Gecko, WebKit), and for Chromium, how many stars those bugs have.
Survey results:
- MDN DNA surveys
- MDN Browser Compatibility Report
- State of CSS most known and used features
Test results from web-platform-tests. For example, flexbox on wpt.fyi.
Can I use's most-searched-for features.

The five top focus areas in 2021 #

In 2020, Chromium started work addressing the top areas outlined in Improving Chromium's browser compatibility in 2020. In 2021, we are beginning a dedicated effort to go even further. Google and Microsoft are working together on addressing top issues in Chromium, along with Igalia. Igalia, who are regular contributors to Chromium and WebKit, and maintainers of the official WebKit port for embedded devices, have been very supportive and engaged in these compatibility efforts, and will be helping tackle and track the identified issues.

Here are the areas which are committed to being fixed in 2021.

CSS flexbox #

CSS flexbox is widely used on the web and there are still some major challenges for developers. For example, both Chromium and WebKit have had issues with auto-height flex containers leading to incorrectly sized images.

Incorrectly sized image due to bugs.

Correctly sized image.
Photo by Alireza Mahmoudi.

Igalia's flexbox Cats blog post dives deeper into these issues with many more examples.

Why it is prioritized #

Surveys: Top issue in MDN Browser Compatibility Report, most known and used in State of CSS
Tests: 85% pass in all browsers
Usage: 75% of page views, growing strongly in HTTP Archive

CSS Grid #

CSS Grid is a core building block for modern web layouts, replacing many older techniques and workarounds. As adoption is growing, it needs to be rock solid, so that differences between browsers is never a reason to avoid it. One area that's lacking is the ability to animate grid layouts, supported in Gecko but not Chromium or WebKit. When supported, effects like this are made possible:

Animated chess demo by Chen Hui Jing.

Why it is prioritized #

Surveys: Runner-up in MDN Browser Compatibility Report, well known but less often used in State of CSS
Tests: 75% pass in all browsers
Usage: 8% and growing steady, slight growth in HTTP Archive

CSS position: sticky #

Sticky positioning allows content to stick to the edge of the viewport and is commonly used for headers that are always visible at the top of the viewport. While supported in all browsers, there are common use cases where it doesn't work as intended. For example, sticky table headers aren't supported in Chromium, and although now supported behind a flag, the results are inconsistent across browsers:

Chromium with "TablesNG"

Gecko

WebKit

Check out the sticky table headers demo by Rob Flack.

Why it is prioritized #

Surveys: Highly known/used in State of CSS and was brought up multiple times in MDN Browser Compatibility Report
Tests: 66% pass in all browsers
Usage: 8%

CSS aspect-ratio property #

The new aspect-ratio CSS property makes it easy to maintain a consistent width-to-height ratio for elements, removing the need for the well-known padding-top hack:

Using padding-top

.container {
  width: 100%;
  padding-top: 56.25%;
}

Using aspect-ratio

.container {
  width: 100%;
  aspect-ratio: 16 / 9;
}

Because it is such a common use case this is expected to become widely used, and we want to make sure it's solid in all common scenarios and across browsers.

Why it is prioritized #

Surveys: Already well known but not yet widely used in State of CSS
Tests: 27% pass in all browsers
Usage: 3% and expected to grow

CSS transforms #

CSS transforms have been supported in all browsers for many years and are widely used on the web. However, there still remain many areas where they don't work the same across browsers, notably with animations and 3D transforms. For example, a card flip effect can be very inconsistent across browsers:

Card flip effect in Chromium (left), Gecko (middle) and WebKit (right). Demo by David Baron from bug comment.

Why it is prioritized #

Surveys: Very well known and used in State of CSS
Tests: 55% pass in all browsers
Usage: 80%

How you can contribute and follow along #

Follow and share any updates we post on @ChromiumDev or the public mailing list, Compat 2021. Make sure bugs exist, or file them for issues you have been experiencing, and if there's anything missing, reach out through the above channels.

There will be regular updates about the progress here on web.dev and you can also follow the progress for each focus area in the Compat 2021 Dashboard.

The Compat 2021 Dashboard (screenshot taken 16 November, 2021).

We hope this concerted effort among browser vendors to improve reliability and interoperability will help you go build amazing things on the web!

Introducing Open Web Docs

2021-01-25T00:00:00Z

High-quality documentation for web platform technologies is a critically important component of our shared, open digital infrastructure. Today, I'm excited to publicly introduce Open Web Docs, a collective project between Google, Microsoft, Mozilla, Coil, W3C, Samsung, and Igalia. It is designed to support a community of technical writers around strategic creation and long-term maintenance of web platform technology documentation that is open and inclusive for all.

This is not a new docs platform: Open Web Docs is instead working closely with existing platforms, and its current priority is contributions to MDN Web Docs. It was created to ensure the long-term health of web platform documentation on de facto standard resources, independently of any single vendor or organization. Through full-time staff, community management, and Open Web Docs' network of partner organizations, it enables these resources to better maintain and sustain documentation of core web platform technologies. Rather than create new documentation sites, Open Web Docs is committed to improving existing platforms through our contributions.

Head over to Open Web Docs and the launch post and FAQ to learn more!

How to file a good browser bug

2020-06-15T00:00:00Z

Filing a good bug isn't hard, but takes a little work. The goal is to make it easy to find what's broken, reach the root cause and, most importantly, find a way to fix it. Bugs that make fast progress tend to be easy to reproduce with a clear expected behavior.

Verify it is a bug #

The first step is to figure out what the "correct" behavior should be.

What's the correct behavior? #

Check the relevant API docs on MDN, or try to find related specs. This information can help you decide which API is actually broken, where it's broken, and what the expected behavior is.

Does it work in a different browser? #

Behavior that differs between browsers is generally prioritized higher as an interoperability issue, especially when the browser containing the bug is the odd one out. Try to test on the latest versions of Chrome, Firefox, Safari and Edge, possibly using a tool like BrowserStack.

If possible, check that the page isn't intentionally behaving differently due to user agent sniffing. In Chrome DevTools, try setting the User-Agent string to another browser.

Did it break in a recent release? #

Did this work as expected in the past, but broke in a recent browser release? Such "regressions" can be acted upon much quicker, especially if you supply a version number where it worked and a version where it failed. Tools like BrowserStack can make it easy to check old browser versions and the bisect-builds tool (for Chromium) allows searching for the change very efficiently.

If an issue is a regression and can be reproduced, the root cause can usually be found and fixed quickly.

Are others seeing the same problem? #

If you're experiencing problems, there's a good chance other developers are too. First, try searching for the bug on Stack Overflow. This might help you translate an abstract problem into a specific broken API, and it might help you find a short term workaround until the bug is fixed.

Has it been reported before? #

Once you have an idea of what the bug is, it's time to check to see if the bug has already been reported by searching the browser bug database.

Chromium-based browsers: https://crbug.com
Firefox: https://bugzilla.mozilla.org/
Safari & WebKit-based browsers: https://bugs.webkit.org/

If you find an existing bug that describes the problem, add your support by starring, favoriting, or commenting on the bug. And, on many sites, you can add yourself to the CC list and get updates when the bug changes.

If you decide to comment on the bug, include information about how the bug affects your website. Avoid adding "+1" style comments, as bug trackers typically send emails for every comment.

Report the bug #

If the bug hasn't been reported before, it's time to tell the browser vendor about it.

Create a minimized test case #

Mozilla has a great article on how to create a minimized test case. To make a long story short, while a description of the problem is a great start, nothing beats providing a linked demo in the bug that shows the problem. To maximize the chance of fast progress the example should contain the minimum possible code needed to demonstrate the problem. A minimal code sample is the number one thing you can do to increase the odds of your bug getting fixed.

Here are a few tips for minimizing a test case:

Download the web page, add <base href="https://original.url"> and verify that the bug exists locally. This may require a live HTTPS server if the URL uses HTTPS.
Test the local files on the latest builds of as many browsers as you can.
Try to condense everything into 1 file.
Remove code (starting with things you know to be unnecessary) until the bug goes away.
Use version control so that you can save your work and undo things that go wrong.

Hosting a minified test case #

If you're looking for a good place to host your minified test case, there are several good places available:

Be aware that several of those sites display content in an iframe, which may cause features or bugs to behave differently.

Filing your issue #

Once you've got your minimized test case, you're ready to file that bug. Head over to the right bug tracking site, and create a new issue.

Chromium-based browsers - https://crbug.com/new
Firefox - https://bugzilla.mozilla.org/
Safari & WebKit-based browsers - https://bugs.webkit.org/

Provide a clear description and the steps required to reproduce the issue #

First, provide a clear description to help engineers quickly understand what the problem is and help to triage the issue.

When installing a PWA using the `beforeinstallprompt.prompt()`, the
`appinstalled` event fires before the call to `prompt()` resolves.

Next, provide the detailed steps required to reproduce the issue. This is where your minified test case comes in.

What steps will reproduce the problem?
1. Go to https://basic-pwa.glitch.me/, open DevTools and look at the
   console tab.
2. Click the Install button in the page, you might need to interact with
   the page a bit before it becomes enabled.
3. Click Install on the browser modal install confirmation.

And finally, describe the expected, and actual result.

What is the expected result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
   (logged when beforeinstallprompt.prompt()` resolves)
2. INSTALL: Success (logged when `appinstalled` event fired)

What is the actual result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL: Success (logged when `appinstalled` event fired)
2. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
   (logged when beforeinstallprompt.prompt()` resolves)

For more information, check out Bug report writing guidelines on MDN.

Bonus: Add a screenshot or screencast of the issue #

Though not required, in some cases, it can be helpful to add a screenshot, or screencast of the issue. This is especially helpful in cases where bugs may require some odd steps to reproduce. Being able to see what happens in a screencast, or on a screenshot can frequently be helpful.

Include details of the environment #

Some bugs are reproducible only on certain operating systems, or only on specific kinds of displays (for example, low-dpi or high-dpi). Be sure to include the details of any test environments you used.

Submit the bug #

Finally, submit the bug. Then, remember to keep an eye on your email for any responses to the bug. Typically during investigation and when fixing the bug, engineers may have additional questions, or if they have difficulty reproducing the issue, they may reach out.