InterOp - what can we actually expect this year?
Tags: webdev, css, javascript
Published: 2023-03-18 12:18:14


Since 2021, the InterOp initiative (initially called Compat 2021) gathered the major browser vendors and some consulting parties, to solve the top browser compatibility issues. They create a list of focus areas and investigations each year to work on. This colloboration has yielded positive results and has been well-received by the front-end community.

However, it is vague what they are delivering! Let's see if we can uncover what we can expect from this initiative.

## InterOp 2023 proposed improvements

Interop 2023 covers 2 types of improvements:

1. **Focus areas** cover parts of the platform where there is already a high quality specification and good test coverage in  web-platform-tests. Progress is measured by looking at the pass rate of those tests across implementations.
2. **Investigations** are for areas where interoperability is lacking, but progress cannot be made by passing existing tests. The reasons for this could be that there is not a good specification or tests for an area, or areas might be hard to test due to missing test infrastructure.

Many of the focus areas do not have clear, explicit objectives. In many cases, it is not obvious what is expected to be delivered, or what underlying issues are being solved. The complete list of focus areas can be seen in the [Interop 2023 readme](https://github.com/web-platform-tests/interop/blob/main/2023/README.md#focus-areas).

<img src="https://www.roboleary.net/assets/img/blog/2023-03-18-interop-what-can-we-expect/focus-area-readme-excerpt.png" alt="excerpt of the focus area from interop readme showing grid and has selector item with light descriptions" width="1389" height="561" loading="lazy">

As you can see from the screenshot above, the `:has()` focus area has a description of *TODO*!

Each of the stakeholders wrote an announcement blog post of their participation. For the most part they are declaring their involvement, but Apple takes some time to outline the focus areas:

- Apple – [Pushing Interop Forward in 2023](https://webkit.org/blog/13706/2023-03-18-interop-what-can-we-expect/)
- Bocoup – [Interop 2023 Update](https://bocoup.com/blog/2023-03-18-interop-what-can-we-expect)
- Google – [Interop 2023](https://web.dev/2023-03-18-interop-what-can-we-expect/)
- Igalia – [Interop 2023](https://www.igalia.com/news/2023/interop2023.html)
- Microsoft – [Microsoft Edge and Interop 2023](https://blogs.windows.com/msedgedev/2023/02/01/microsoft-edge-and-interop-2023/)
- Mozilla - [Announcing Interop 2023](https://hacks.mozilla.org/2023/02/announcing-interop-2023/)

There is more info buried in the [proposals](https://github.com/orgs/web-platform-tests/projects/2) and [test suites](https://wpt.fyi/2023-03-18-interop-what-can-we-expect). I will do some digging later to try to consolidate this information.

I think that the project would benefit from clearer objectives. Reporting can become disingenuous if little is explicitly stated in advance and everything is tied to a test suite.

It appears that ambitions have grown in InterOp 2023, there are **26 focus areas this year, up from 15 last year**. Considering that they didn't complete everything last year -- more than half of the focus areas from 2022 were incomplete -- it seems like a big ask. I applaud the audacity, but I wonder if the resources and motivation are sufficient for each of the browser engines to deliver?

Particularly, I wonder if Firefox can handle the load. In 2020, [Mozilla laid off 25% of its workforce](https://layoffs.fyi/tag/mozilla/). The headcount of the entire company is now about 750 going off figures quoted in 2020. Mozilla's contract with Google to have Google as [the default search provider for Firefox was extended until this year](https://www.zdnet.com/article/sources-mozilla-extends-its-google-search-deal/). Most of Mozilla's revenue comes from this contract with Google, although they are trying to increase their revenue from [their own commercial products now](https://www.mozilla.org/en-US/firefox/products/).

Something that is a big omission from InterOp in my opinion is *priority*. I would like to see these focus areas ordered according to priority - if everything is important, nothing is important! When November comes and the heat is on, which focus areas will get the final push?

I think it is fair to say that it is outside of the purview of InterOp to tell us everything that is coming for the year. InterOp is not Santa Claus for the web.

<img src="https://www.roboleary.net/assets/img/blog/2023-03-18-interop-what-can-we-expect/santa.jpg" alt="excerpt of the focus area from interop readme showing grid and has selector item with light descriptions" width="1389" height="561" loading="lazy">

Browser vendors still act independently and have different agendas. I would like to see browser vendors communicate more on what they *intend* to do in general.

<img src="https://www.roboleary.net/assets/img/blog/2023-03-18-interop-what-can-we-expect/future.jpg" alt="excerpt of the focus area from interop readme showing grid and has selector item with light descriptions" width="1389" height="561" loading="lazy">

Let's review the focus areas and see what we can expect.

## Interop 2023 focus areas explained

I will discuss each focus area to *try* to uncover what we can expect in the coming year from InterOp.

### 1. Border image (CSS)

The `border-image` CSS property draws an image around a given element. It replaces the element's [border](https://developer.mozilla.org/en-US/docs/Web/CSS/border). It opens up a world of possibilities for how a border can look.

For example, [this codepen](https://codepen.io/robjoeol/pen/zYJOGjx) demonstrates having a brass picture frame as the border image for text content. You can edit the text and resize the content area to see how the border stretches to cover the change in dimensions.

<iframe height="366" style="width: 100%;" scrolling="no" title="Framed content" src="https://codepen.io/robjoeol/embed/zYJOGjx?default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/robjoeol/pen/zYJOGjx">
  Framed content</a> by Rob (<a href="https://codepen.io/robjoeol">@robjoeol</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>

 **The `border-image` property is in all major browsers. InterOp aims to make the improvements required to make it consistent across all browsers**.

[MDN has the following warning currently when using the property](https://developer.mozilla.org/en-US/docs/Web/CSS/border):

> **Note:** You should specify a separate [`border-style`](https://developer.mozilla.org/en-US/docs/Web/CSS/border-style) in case the border image fails to load. Although the specification doesn't strictly require it, some browsers don't render the border image if [`border-style`](https://developer.mozilla.org/en-US/docs/Web/CSS/border-style) is `none` or [`border-width`](https://developer.mozilla.org/en-US/docs/Web/CSS/border-width) is `0`.

### 2. Color spaces and functions (CSS)

It is not clear what Interop 2023 will do in this focus area exactly.

**I assume it is to do with implementing the [CSS Color Module Level 4](https://w3c.github.io/csswg-drafts/css-color/) specification completely and consistently across all major browsers, and maybe some of [CSS Color Module Level 5](https://w3c.gith,ub.io/csswg-drafts/css-color-5/#color-mix) specification.**

In summary, the CSS Color Module Level 4 specification adds new color spaces such as *lab* and *lch* that enable a richer range of colors to be used on the web, along with providing more flexible and consistent syntaxes for existing color functions.

[As Lea Verou of the CSS working group put it with regard to color spaces](http://lea.verou.me/):

> Our websites are washed out because screens advanced faster than CSS Color did. If we want to make full use of the range of colors that the majority of screens are capable of displaying, we need to use new CSS colors formats: `lab`, `lch` or `display-p3`.

The new features in this specification are:

1. [lab()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-lab), [lch()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-lch), [oklab()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-oklab) and [oklch()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-oklch) functions for device-independent color.
1. CSS colors are no longer restricted to the narrow gamut of sRGB. The wide color gamut RGB color space is predefined now.

<figure>
<img src="https://www.roboleary.net/assets/img/blog/2023-03-18-interop-what-can-we-expect/rgb-colorspace.png" alt=" This is a map that compares how much of the color spectrum (that large oval in the far back) different color spaces cover. ProPhoto RGB covers the most of the spectrum, Adobe RGB is the second largest, and sRGB is the smallest. Also shown is the color limits of the Epson 2200 printer." width="661" height="679" loading="lazy">
<figcaption>RGB color spaces, Attribution: <a href="https://commons.wikimedia.org/wiki/File:Colorspace.png">Wikimedia</a> under CC BY 2.5</figcaption>
</figure>

**Currently, the support for the new color functions is as follows:**

- **[`lab()`  and `lch()`](https://caniuse.com/css-lch-lab) are in Chrome and Safari,**
- **[`oklab()`](https://caniuse.com/mdn-css_types_color_oklab) is in Safari,**
- **[`oklch()`](https://caniuse.com/mdn-css_types_color_oklch) is in Safari.**

The following syntax changes have been added:

1. [rgb()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-rgb) and [rgba()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-rgba) functions now accept [<number>](https://w3c.github.io/csswg-drafts/css-values-4/#number-value) rather than [<integer>](https://w3c.github.io/csswg-drafts/css-values-4/#integer-value), so that a fractional number can be accepted.
2. [hsl()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-hsl) and [hsla()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-hsla) functions now accept [<angle>](https://w3c.github.io/csswg-drafts/css-values-4/#angle-value) as well as [<number>](https://w3c.github.io/csswg-drafts/css-values-4/#number-value) for hues.
3. [rgb()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-rgb) and [rgba()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-rgba), and [hsl()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-hsl) and [hsla()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-hsla) are now aliases of each other (all of them have an optional alpha).
4. [rgb()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-rgb), [rgba()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-rgba), [hsl()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-hsl), and [hsla()](https://w3c.github.io/csswg-drafts/css-color/#funcdef-hsla) have all gained a new syntax consisting of space-separated arguments and an optional slash-separated opacity. All the color functions use this syntax form now, in keeping with [CSS’s functional-notation design principles](https://wiki.csswg.org/ideas/functional-notation#general-principles).
5. All uses of [<alpha-value>](https://w3c.github.io/csswg-drafts/css-color/#typedef-alpha-value) now accept [<percentage>](https://w3c.github.io/csswg-drafts/css-values-4/#percentage-value) as well as [<number>](https://w3c.github.io/csswg-drafts/css-values-4/#number-value).
6. 4 and 8-digit hex colors have been added, to specify transparency.
7. The [none](https://w3c.github.io/csswg-drafts/css-color/#valdef-color-none) value has been added, to represent powerless components.

These syntax changes appear to be in browsers now.

Read the [High definition CSS color guide](https://developer.chrome.com/articles/high-definition-css-color-guide/) to learn about these new color types and spaces.

The [CSS Color Module Level 5](https://w3c.gith,ub.io/csswg-drafts/css-color-5/#color-mix) specification introduces the `color-mix()` and `color-contrast()` functions.

Google mentioned that the [CSS Color Module Level 5](https://w3c.gith,ub.io/csswg-drafts/css-color-5/#color-mix) specification [was part of the scope for InterOp 2022](https://web.dev/interop-2022/#color-spaces-and-css-color-functions), but it was not done. Is it in scope for this year?

According to [Chrome's Platform Status](https://chromestatus.com/roadmap), [CSS Color Module Level 4 and `color-mix()`](https://chromestatus.com/feature/5147752829288448) are slated for Chrome v111 (March 2023):

> All features described in [CSS Color 4](https://www.w3.org/TR/css-color-4/ ) are now enabled! This includes four device-independent color types (lab, Oklab, lch and Oklch), the color() function and user-defined color spaces for gradients and animations. The incredibly useful color-mix() function from [CSS Color 5](https://www.w3.org/TR/css-color-5/#color-mix) has also been included as a bonus!

<figure>
<img src="https://www.roboleary.net/assets/img/blog/2023-03-18-interop-what-can-we-expect/suspicious.jpg" alt="excerpt of the focus area from interop readme showing grid and has selector item with light descriptions" width="1389" height="561" loading="lazy">
<figcaption>A bonus? Or a year late?</figcaption>
</figure>

The `color-mix()` function has been an experimental feature in Safari and Firefox for some time. It is not clear if it will be adopted properly by all major browsers.

The `color-contrast()` color function is in Safari. My guess is that `color-contrast()` won't make the cut this year.

### 3. Container queries (CSS)

Container queries simplify responsive web design in the web component era. It allow us to apply styles based on the size of a containing element rather than the viewport or other device characteristics. For example, if a container has less space in the surrounding context, you can hide certain elements or use smaller fonts.

<figure>
<img src="https://www.roboleary.net/assets/img/blog/2023-03-18-interop-what-can-we-expect/container-query-diagram.png" alt="figure of a container query to explain difference in scope between media query and container query" width="739" height="499" loading="lazy">
<figcaption>Image attributed to <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries">CSS Container Queries</a> by <a href="https://developer.mozilla.org/en-US/docs/MDN/Community/Roles_teams#contributor">Mozilla Contributors</a> is licensed under CC-BY-SA 2.5.</figcaption>
</figure>

**[Container Queries](https://developer.mozilla.org/docs/Web/CSS/CSS_Container_Queries) shipped last year in Chrome and Safari, Firefox has *just* shipped container queries in Firefox 110 (Feb 2023)! Presumably, the objective is to improve the passing rate for the test suite to ensure that container queries work reliably across browsers. 🤞**

### 4. Containment (CSS)

The objective of the [CSS Containment specification](https://w3c.github.io/csswg-drafts/css-contain) is to improve the performance of web pages by allowing the browser to isolate a subtree of the page from the rest of the page. The specification defines the CSS properties [`contain`](https://developer.mozilla.org/en-US/docs/Web/CSS/contain), [`contain-intrinsic-size`](https://developer.mozilla.org/en-US/docs/Web/CSS/contain-intrinsic-size), and [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) for this.

My naive interpretation of these properties is that `contain` provides a hint to the browser that it can render parts of the page independently, whereas `content-visibility` is more prescriptive where you can say "don't need to render this subsection until it is needed", kind of like lazy loading.

The [proposal for this focus area](https://github.com/orgs/web-platform-tests/projects/2/views/1?pane=issue&itemId=11794698) states:

> The contain CSS property is a prerequisite for content-visibility, but that is already part of Interop 2022. The contain-intrinsic-size property is important to provide an easy way to reserve placeholder sizing for content-visibility subtrees. It also enables full `content-visibility: auto` adoption without the need for any script.

The [`contain` property is in all major browsers now](https://caniuse.com/mdn-css_properties_contain), but it appears `contain` requires more tests to stabilize its usage.

The [`content-visibility` property is in Chrome and Edge](https://caniuse.com/css-content-visibility). Mozilla previously stated that it [is worth prototyping](https://github.com/mozilla/standards-positions/issues/135#issuecomment-650923098).

**Can we surmise that the goal is to get containment completed this year then?**

### 5. Pseudo-classes (CSS)

This focus area covers a collection of CSS pseudo-classes: `:dir()`, `:nth-child()`, `:nth-last-child()`, `:nth-of-type()`, `:nth-last-of-type()`, `:modal`, `:user-valid` and `:user-invalid`.
The objective is to improve interoperability.

### 6. Custom properties (CSS)

Basic support for custom properties has been in browsers a long while. Interop 2023 will **focus on the [@property](https://developer.mozilla.org/docs/Web/CSS/@property) at-rule**, which is part of [CSS Houdini](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Houdini).

The `@property` at-rule allows developers to explicitly define their own custom properties, allowing for property type checking, setting default values, and define whether a property can inherit values or not. It allows you to write semantically meaningful CSS within CSS itself.

For example, you could define your own primary color.

```css
@property --primaryColor {
  syntax: '<color>';
  initial-value: pink;
  inherits: false;
}
```

And use it anywhere like a regular custom property:

```css
.card {
  background-color: var(--primaryColor); 
	/* pink */
}
```

If you assign an incorrect type of value, it will fallback to the default:

```css
.card{
    --primaryColor: 5; 
		/* incorrect type */
    
   background-color: var(--primaryColor); 
	 /* background-color falls back to pink */
}
```

This overcomes [the weird fallback issue](https://adactio.com/journal/16993) with custom properties.

### 7. Flexbox (CSS)

[Flexbox](https://developer.mozilla.org/docs/Learn/CSS/CSS_layout/Flexbox) is a one-dimensional layout method for arranging items in rows or columns. It is a mature, CSS stalwart now. Over that time, the Flexbox specification has matured with both slight behavior changes and updated clarifications of precise details.

Looking at the test suite, it **looks like the goal is to expand test coverage to make flexbox more consistent and stable**.

### 8. Font feature detection and palettes (CSS)

The Interop group describe this focus area as: "enable testing for font stack capabilities and enable additional expressiveness with vector color fonts. ([Font feature detection and palettes](https://github.com/web-platform-tests/interop/issues/164))".

This appears to refer **to widening the capabilities of the `@supports`  at-rule, which has functions that can be used to conditionally check font features through the `font-tech()`, and`font-format()`.**

The `font-tech()` function can check if a browser supports a specified font technology for layout and rendering. For example, the CSS following checks if the browser supports the `COLRv1` font technology (multi-colored glyphs via COLR version 1 table) and if it is supported sets the `font-family` for the document body:

```css
@import url("https://fonts.googleapis.com/css2?family=Bungee+Spice");

@supports font-tech(color-COLRv1) {
    body{
        font-family: "Bungee Spice";
    }
}
```

I do not know much about these new font features. You can read about [color fonts in this post](https://webkit.org/blog/12662/customizing-color-fonts-on-the-web/).

The current browser support is:

- [`font-tech()`](https://caniuse.com/mdn-css_at-rules_supports_font-tech) : Firefox,
- [`font-format()`](https://caniuse.com/mdn-css_at-rules_supports_font-format): Firefox.

### 9. Forms (HTML)

The [<form> HTML element](https://developer.mozilla.org/docs/Web/HTML/Element/form) defines a document section containing interactive controls for submitting information to a server.

Support for vertical text in form fields has been missing. Interop 2023 is a commitment by the industry to change this.

This focu area also carries over the tests from Interop 2022. This includes tests for the appearance property, form, events on disabled form controls, input elements, form submission, and form validation.

### 10. Grid (CSS)

[CSS Grid](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout) is a layout method that provides a two-dimensional grid system.

Looking at [the test suite](https://wpt.fyi/results/css/css-grid?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2021-grid%20or%20label%3Ainterop-2023-grid), it looks **like the goal is to expand test coverage to make grid more consistent and stable**.

### 11. The `:has()` pseudo-class (CSS)

Developers have been wishing for a parent selector in CSS *forever*. 😅 The [`:has()`](https://developer.mozilla.org/docs/Web/CSS/:has) pseudo-class makes possible many of the use cases for a parent selector, as well as the selection of a previous sibling element with respect to a reference element.

**The [`:has()` pseudo-class landed in Chrome and Safari last year, but it is still in an experimental state in Firefox.](https://caniuse.com/css-has). It will take more effort this year for it to be consistently implemented across all browsers.**

### 12. The `inert`  attribute (HTML)

The [`inert` HTML attribute](https://developer.mozilla.org/docs/Web/API/HTMLElement/inert) makes the browser ignore user input events for an element. This can be useful when building UIs such as modals where you would want to "trap" the focus inside the modal when it's visible.

**[The `inert` attribute is in Chrome and Safari. I guess that it will be coming soon to Firefox?](https://caniuse.com/mdn-api_htmlelement_inert)**

### 13. Masking (CSS)

Support for [CSS masking](https://developer.mozilla.org/docs/Web/CSS/CSS_Masking) is patchy. **Using masking is harder to use than it should be. This focus area will help developers to confidently use creative masking effects cross-browser.**

This was on my wishlist for CSS improvements that I discussed in my previous article.

### 14. Math functions (CSS)

New groups of math functions are proposed in the [CSS Values and Units Module Level 4 specification](https://drafts.csswg.org/css-values/#math). **The implementation of these math functions has been sporadic so far, presumably the expectation is that the following functions will be added in the next year**:

- trigonometric calculations such as:
  - [`sin()`](https://developer.mozilla.org/en-US/docs/Web/CSS/sin): Calculates the trigonometric sine of a number.  
  - [`cos()`](https://developer.mozilla.org/en-US/docs/Web/CSS/cos): Calculates the trigonometric cosine of a number.  
  - [`tan()`](https://developer.mozilla.org/en-US/docs/Web/CSS/tan): Calculates the trigonometric tangent of a number.  
  - [`asin()`](https://developer.mozilla.org/en-US/docs/Web/CSS/asin): Calculates the trigonometric inverse sine of a number.  
  - [`acos()`](https://developer.mozilla.org/en-US/docs/Web/CSS/acos): Calculates the trigonometric inverse cosine of a number.  
  - [`atan()`](https://developer.mozilla.org/en-US/docs/Web/CSS/atan): Calculates the trigonometric inverse tangent of a number.  
  - [`atan2()`](https://developer.mozilla.org/en-US/docs/Web/CSS/atan2): Calculates the trigonometric inverse tangent of two-numbers in a plane.  
- exponential functions such as:
  - [`pow()`](https://developer.mozilla.org/en-US/docs/Web/CSS/pow): Calculates the base raised to the power of a number.  
  - [`sqrt()`](https://developer.mozilla.org/en-US/docs/Web/CSS/sqrt) : Calculates the square root of a number.  
  - [`hypot()`](https://developer.mozilla.org/en-US/docs/Web/CSS/hypot) : Calculates the square root of the sum of the squares of its arguments.  
  - [`log()`](https://developer.mozilla.org/en-US/docs/Web/CSS/log) : Calculates the logarithm of a number.  
  - [`exp()`](https://developer.mozilla.org/en-US/docs/Web/CSS/exp): Calculates `e` raised to the power of a number.  
- sign-related functions such as:
  - [`abs()`](https://developer.mozilla.org/en-US/docs/Web/CSS/abs): Calculates the absolute value of a number.  
  - [`sign()`](https://developer.mozilla.org/en-US/docs/Web/CSS/sign): Calculates the sign (positive or negative) of the number.  
- stepped values such as:
  - [`round()`](https://developer.mozilla.org/en-US/docs/Web/CSS/round) : Calculates a rounded number based on a rounding strategy.  
  - [`mod()`](https://developer.mozilla.org/en-US/docs/Web/CSS/mod): Calculates a modulus (with the same sign as the divisor) when dividing one number by another.  
  - [`rem()`](https://developer.mozilla.org/en-US/docs/Web/CSS/rem) : Calculates a remainder (with the same sign as the dividend) when dividing one number by another.  

The browser support and indications for implementation of the math functions are as follows:
- **Trigonometric functions** : Chrome will [ship the trigonometric functions in the next version, v111](https://chromestatus.com/feature/5165381072191488). Then, the trigonometric functions will be in all major browsers.
- **Exponential functions**: Are in Safari.
- **Sign-related functions**: Are in Safari, are under development in Chrome, and there is no signal from Firefox about development.
- **Stepped values functions**: Are in Safari, Firefox has `rem()` and `round()` implemented as an experimental features.

If you are wondering what use these math functions are, here are some use cases:
- Can improve data visualization and charts. Especially for frameworks like [Charts.CSS](https://chartscss.org/) that use no JavaScript.
- Trigonometric functions can be usd to place items on a shape.
- Satisfy additional needs inside CSS animations such as symmetries in staggered animations, and animating shadows in 3D scenes.
- For fluid layouts, you can replace units with more complex calculations.

Ana Tudor wrote an article an inspiring article titled [Using Absolute Value, Sign, Rounding and Modulo in CSS Today](https://css-tricks.com/using-absolute-value-sign-rounding-and-modulo-in-css-today/#aa-use-cases) listing some use cases for math, and some work arounds to do things with these math functions.

### 15. Media queries 4 (CSS)

[Media Queries](https://developer.mozilla.org/docs/Web/CSS/Media_Queries/Using_media_queries) allow you to apply CSS styles depending on the medium (print or screen), or a device's characteristics such as screen resolution or browser viewport width.

**This focus area is to implement the [Media Queries Level 4 specification](https://drafts.csswg.org/mediaqueries-4/). The specification has reasonable support in modern browsers, but some media features are not well supported.**

The major additions are:

- [Media features](https://drafts.csswg.org/mediaqueries-4/#media-feature) with numeric values can now be written in a [range context](https://drafts.csswg.org/mediaqueries-4/#mq-range-context). For example,  `@media (width <= 30em){ /* .. */ }` is the equivalent of `@media (max-width: 30em){ /* .. */ }`.
- The `pointer`, `any-pointer`, `hover`, `any-hover`, `update`, `color-gamut`, `overflow-block`, and `overflow-inline` media features were added.

### 16. Modules in Web Workers (JavaScript)

Web Workers are a simple means to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface.

Until now, it is a bit clunky to organize your code when writing a web worker. An `importScripts()` function is available within web workers for loading additional code, but it pauses execution of the worker in order to fetch and evaluate each script. It also executes scripts in the global scope like a `<script>` tag, which means you can have some unwanted side effects if you are not mindful.

[JavaScript modules](https://v8.dev/features/modules) will be added to web workers to address these shortcomings. They are referred to as module workers. The `Worker` constructor now accepts a new `{type:"module"}` option, which changes script loading and execution to match `<script type="module">`.

```javascript
const worker = new Worker('worker.js', {
  type: 'module'
});
```

In the module worker, you can use `import` and `export` statements. Dependencies are only executed once in the given context, and all future imports reference the already-executed module instance.

**It looks like [this is in all major browsers now except for Firefox](https://caniuse.com/mdn-api_worker_worker_ecmascript_modules). The expectation is that Firefox will add support this year.**

You can read this web.dev article for more info on module workers - [Threading the web with module workers](https://web.dev/module-workers/).

### 17. Motion path (CSS)

[Motion Path](https://developer.mozilla.org/docs/Web/CSS/CSS_Motion_Path) allows animation of any graphical object along a custom path. This enables the addition of more dynamic movement in CSS animations.

**Motion Path is [now supported in all major browsers](https://caniuse.com/css-motion-paths), but there are failing tests in the test suites that need attention. This focus area is to reach a higher bar of interoperability.**

You can explore some examples in the following article - [CSS Motion Path: The end of GSAP?](https://blog.logrocket.com/css-motion-path-the-end-of-gsap/).

### 18. OffscreenCanvas API (JavaScript)

This is one that I am excited about!

The [`canvas`](https://developer.mozilla.org/docs/Web/HTML/Element/canvas) element and Canvas API provide a scriptable way to draw graphics in a web page. However, this can cause performance problems as the work is performed on the same thread as user interaction. [OffscreenCanvas](https://developer.mozilla.org/docs/Web/API/OffscreenCanvas) offers developers a canvas which is decoupled from the DOM and the  Canvas API. Developers can run rendering tasks in a Web Worker, separate from the main thread.

**Currently, [OffscreenCanvas is in Chrome and Firefox, and has just arrived in Safari as an experimental feature](https://caniuse.com/offscreencanvas). The test suite suggests that the objective is to get a consistent outcome across the browsers.**

### 19. Pointer and Mouse Events (JavaScript)

[Pointer and mouse events](https://developer.mozilla.org/docs/Web/API/Pointer_events) are DOM events that are fired for a pointing device such as a mouse, pen, stylus, or touch (such as one or more fingers).

**This focus area looks to improve pointer and mouse events with regard to hit accuracy and scrolling areas. Interop have decided to explicitly exclude touch and stylus inputs due to lack of WPT testing support across all browsers.**

### 20. Scrolling (CSS)

The focus area is a carryover from Interop 2022. There’s more work to do to increase interoperability, so everyone agreed to include it again.

The [`scroll-behavior`](https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-behavior), [`overscroll-behavior`](https://developer.mozilla.org/en-US/docs/Web/CSS/overscroll-behavior), and the [scroll-snap CSS properties](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Scroll_Snap) allow authors to influence how scrolling behaves.

**It appears that all major browsers have implemented the scroll-related properties outlined in the [CSS Overflow Module Level 3 specification](https://drafts.csswg.org/css-overflow-3/). The [test suite](https://wpt.fyi/results/css?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2022-scrolling) suggests that it is a question of ironing out issues.**

### 21. Subgrid (CSS)

Subgrid allows a grid item with its own grid to align in one or both dimensions with its parent grid.

**Subgrid is [currently supported in all major browsers *except* Chromium-based browsers](https://caniuse.com/css-subgrid). It is [under development for Chrome](https://www.chromestatus.com/feature/5663795354533888).**

### 22. Transforms (CSS)

This focus area is continued on from Interop 2021.

The `transform` CSS property lets you rotate, scale, skew, or translate an element in two- or three-dimensional space. Over the last two years, engineers at Firefox, Chrome and Safari have been closely collaborating to improve the interoperability of 3D.

**Interop 2023 aims to raise the number of tests that pass in all three browser engines up from its current 92.8%.**

### 23. URL API (JavaScript)

The [URL API](https://developer.mozilla.org/docs/Web/API/URL) is used to parse, construct, normalize, and encode URLs.

This focus area is to **get all browsers to agree on the implementation of URLs as defined in the URL Standard**.

You should not need to manipulate URLs client-side very often, we are moving away from Single Page Apps right? 😅

### 24. Web Codecs API (JavaScript)

The [WebCodecs API](https://developer.mozilla.org/docs/Web/API/WebCodecs_API) gives web developers low-level access to the individual frames of a video stream, and fragments of audio. This is useful for web apps that require full control over the way media is processed. such as video editors, and video conferencing apps.

**The Web Codecs API is [supported in Chrome and Firefox, and just arrived in Safari as an experimental feature](https://caniuse.com/webcodecs). Interop 2023 will focus on the video processing portion of WebCodecs.**

### 25. Web Compat 2023 (CSS and JavaScript)

This is a **catchall focus area for small bugs that cause known site compatibility issues**.

For 2023, a whole new set of tests have been selected. They include tests for Regex Lookbehind, inline editing, event dispatching on disabled controls, CSS image-set, white-space, and text-emphasis.

### 26. Web Components

[Web Components](https://developer.mozilla.org/docs/Web/Web_Components) are a suite of different technologies that enable the creation of reusable custom elements. They enable building web apps in a similar manner to popular UI frameworks such as React.

**Interop 2023 README states that they will focus on improving the interoperability of these foundational technologies including Constructable stylesheets, adoptedStyleSheets, ElementInternals, Form-associated Custom Elements, and the basic behavior of Shadow DOM and Custom Elements.**

I won't comment on this one, because I find the story of web components bewildering. It is something that I would like to delve into.

## Is Interop focusing on the right things?

This is quite a subjective question. Your answer will depend on: whether you work on the [front-of-the-front-end or back-of-the-front-end](https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/), what kind of day job you have (pain points you feel on a daily basis), what your interests are (side projects and hobbies), and what your preferences are for tools and tech stacks.

I think last year, the focus areas were well short of what is important to an average developers. This year they look more in line with what a typical developer would like to see.

## Final thoughts

I would be delighted if the proposals in InterOp are delivered. InterOp 2023 is ambitious. I am skeptical about the capacity to execute. It will be interesting to revisit this next year to see if this is an accurate forecast of features and improvements coming to browsers. Fingers crossed!

---

You can subscribe to my [RSS feed](https://www.roboleary.net/feed.xml) to get my latest articles.