When we looked into JPEG XL, I asked developers why they were interested in the format, and the most common answer was "progressive rendering". This is now working in Firefox and Chrome, but doesn't work in Safari. In addition to this, AVIF's progressive decode became much more viable this year following enhancements to the avifenc encoder. Currently, Chrome is the only browser that supports rendering the intermediate steps (demo). I propose this as a focus area, so we get good progressive decoding support across both formats.
Interop 2027 proposals
CSS border-shape (CSS Borders and Box Decorations Module Level 4) lets authors define an element’s border geometry using <basic-shape> values (circle(), ellipse(), polygon(), inset(), shape(), path(), rect()) instead of a rectangle. It has two modes: a single shape “stroke” mode, where the border is drawn along the path, and a two shape “fill” mode, where the border fills the area between an outer and inner shape. Unlike clip-path, which only masks the rendered box, border-shape redefines the actual border geometry, so background, border image, outline and box shadow all correctly follow the new shape. It removes the need for clip-path plus pseudo element hacks for things like speech bubbles, scalloped cards, cut corner tooltips and hexagonal avatars.
CSS currently provides several ways to define and manipulate colors, that are independent of any particular RGB gamut, such as oklch() or lab(). While this makes it easier to define and manipulate colors in ways that are closer to human perception, it also makes it much easier to define colors that fall **outside of the display gamut of any output device**, especially when **modifying existing colors** (that are in gamut to begin with!), such as when creating color ramps from a dynamic accent color. For example, pick _any_ non-neutral accent color (e.g. #0075ff, Chrome’s default AccentColor value), and adjust its OKLCh lightness to 97% to produce a tinted background color. The result (oklch(from #0075ff 97% c h) or oklch(0.97 0.2235 258.41)) is **outside the display gamut of any conceivable display device**. Without gamut mapping (i.e. currently in most UAs), this is displayed via converting to RGB, and **clipping red, green, blue coordinates**. This produces colors **dramatically** different than the specified color, losing all guarantees that these color spaces were supposed to provide. This carries **accessibility implications** as well, since RGB clipping can significantly affect contrast characteristics, making color pairs inaccessible. See here a particularly egregious example where **white is displayed as blue in non-GM browsers** (bsky post). To display these colors correctly they need to be **mapped to the closest in-gamut color**, typically by reducing chroma (≈ saturation) while preserving hue and lightness. Here is a visual of the example above, with each color as a dot shown relative to the P3 gamut: <table> <thead><tr> <th></th> <th><a href="https://apps.colorjs.io/gamut/?color=%230075ff"><code>#0075ff</code></a></th> <th><a href="https://apps.colorjs.io/gamut/?color=oklch(97%%200.2235%20258.41)"><code>oklch(from #0075ff 97% c h)</code></a></th> <th><a href="https://apps.colorjs.io/gamut/?color=oklch(97%%200.015%20258.41)"><code>oklch(from #0075ff 97% c h)</code>, gamut mapped to P3</a></th> </tr></thead> <tr><th>Color</th><td> </td><td> </td><td> </td></tr> <tr><th>Color relative to P3 gamut</th><td> </td><td> </td><td> </td></tr> </table> Notice how **the gamut shrinks dramatically as we get towards white** (100%) or black (0%), so a color that was perfectly in-gamut for midtones, can be _wildly_ out of gamut for lighter tints. We promised authors that color spaces like oklch() + relative colors would let them create dynamic color ramps, but that promise was never realized due to the lack of GM. CSS Color 4 defines three gamut mapping algorithms that browsers can pick from (comparison), but so far only Firefox has shipped an implementation. **Soon, it may be too late to fix this due to web compat.** This was previously submitted in 2024 by @romainmenke in #443 and rejected on the basis of lacking testing infrastructure. There are currently more tests than there were back then. Canvas makes it easier to test at least for specific colorSpace values. In terms of implementations, **Firefox** has implemented GM behind a flag and Chrome and WebKit are reportedly looking into it.
The moveBefore() function moves elements within the DOM without losing various states, such as animation and transition state, :focus, open/close state of popovers, and <iframe> loading state.
The Temporal API is the modern replacement for the legacy Date object in JavaScript. It provides immutable date/time types, proper time zone support, calendar systems, and nanosecond precision. Temporal has reached **Stage 4** in TC39 and is already shipping in Chrome/Edge and Firefox. Safari/WebKit still lacks full support (or has incomplete support). This creates a significant interoperability gap for a fundamental language feature that developers have been waiting for for many years. Because Temporal is designed as a full replacement for Date, incomplete support forces developers to either: - Continue using the broken Date API - Ship large polyfills - Use feature detection + dual code paths Making Temporal fully interoperable across all major engines would remove one of the longest-standing pain points in the JavaScript language.
The Customizable Select feature will allow developers to provide custom styled dropdown menus in a way that takes advantage of native browser accessibility features such as keyboard interaction. Currently, it is common practice to create entirely custom JavaScript-driven alternatives to the native <select> element when significant custom styling of a dropdown menu is needed, which often leads to accessibility problems and other issues. The Customizable Select feature will address this.
CSS module scripts allow a CSS file to be imported as a constructable stylesheet using the JavaScript module import syntax: Shipped in Chromium and Gecko, not in WebKit.
Embedding third-party content (e.g., payment widgets, comment sections, social posts, live charts, embedded demos) is one of the most fundamental architecture patterns on the web. However, <iframe> elements have historically been unable to automatically size themselves to the natural dimensions of their embedded documents without producing scrollbars or requiring brittle postMessage() polyfills . Responsive Iframes (part of CSS Box Sizing Module Level 4) introduces a standardized, security-preserving mechanism for seamless frame sizing and consists of three parts: - Embedding Opt-in: The parent document specifies frame-sizing: content-height | content-width | content-block-size | content-inline-size | none on the <iframe> - Embedded Opt-in: The embedded document includes <meta name="responsive-embedded-sizing"> to explicitly authorize sharing its layout intrinsic size - Dynamic Updates: The embedded document can trigger re-measurements via window.requestResize()
After two rounds of anchor positioning focus areas in Interop 2025 and 2026, the following gaps remain: - Positioned elements should correctly respond to transformed anchors. - Positioned elements should correctly respond to transitioned/amnimated anchors.
Linked parameters provides three ways for developers to style SVG images.
The CSS interpolate-size property allows a page to opt in to animations and transitions of CSS intrinsic sizing keywords such as auto, min-content, fit-content, etc. A common use case is to transition between height: 0 and height: auto, for example in accordion components. Closely related is the new calc-size() function, which allows you to perform calculations on intrinsic size values (not supported by the regular calc() function). These features are supported in Chrome v129. References: - https://developer.chrome.com/docs/css-ui/animate-to-height-auto - https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/calc-size
This seems like a yearly affair to ask for unprefixed CSS line-clamp. The major use cases are to clamp lines of text in a card UI. So far, web developers need to use a very specific hack to achieve such UI, like the example shown in MDN: Since the line-clamp draft proposal is specified in CSS Overflow Module 4, it would be best to continue the effort for implementation. From the last year's proposal, it seemed to have gathered quite a number of positive feedback, but alas it was not chosen for Interop 2026. Therefore I'd like to re-raise it again for Interop 2027
Element Scoped View Transitions extends same document view transitions (a.k.a document.startViewTransition) to work on element subtrees (i.e. element.startViewTransition). The transition is limited to that subtree. This also allows multiple transitions to run in independent scopes.
I propose an investigation of CSS element() which lets a page use the appearance of one element as an image elsewhere on the same page. The first target would be backgrounds that follow changes to their source, such as a small page preview or a canvas used in several places. The investigation would establish a useful, clearly specified subset and build tests that browser teams can share. It would cover simple sources, live updates, image size, missing references, and reference loops.
- The setHTML() method inserts HTML into the DOM in a way that prevents cross-site scripting attacks. - The parseHTML() method of the Document object provides an XSS-safe method to parse and sanitize a string of HTML in order to create a new Document. I will limit the scope to setHTML() and Document.parseHTML(). There are separate Interop proposals for the new HTML setter methods and for the streaming methods, so please also vote for those.
The CSS if() function allows devs to use conditional logic to set property values. This feature has shipped in Chrome 137, with some level of development happening in Firefox and Safari.
Explainer: https://open-ui.org/components/scoped-focusgroup.explainer/ focusgroup is a proposed HTML attribute that replaces the hand-rolled "roving tabindex" logic every UI library reimplements for toolbars, tabs, menus, listboxes, and radiogroups. Adding something like focusgroup="toolbar wrap" to a container gives its children directional (e.g. arrow key) navigation between items, a single guaranteed tab stop, and memory of the last-focused item, without JavaScript (selection state remains the author's responsibility). Support for focusgroup landed in Chrome 150.
A way to display visible separators between items in grid, flex and multi-column layouts rather than resorting to border or pseudo-element hacks.
The @function CSS at-rule enables defining CSS custom functions. Once defined, a custom function can be called using the <dashed-function> syntax (for example, --my-function(30px, 3)) within any property value. This feature has shipped in Chrome 139, with Safari including it in Safari Tech Preview 249%20(181625123)).
This is an extension of the proposal in #1336 to cover the new HTML setters and streaming setter methods, and the integration with trusted types. The Sanitizer API is providing a new method to modify HTML without causing XSS, which is one of the most prevalent security vulnerabilities in the world. In order for developers to be able to depend on these features it's necessary for them to be reliable cross-browser. Note that, although this feature is an unmerged PR at the time of writing, we are confident it will be merged in plenty of time for Interop.
I proposed a general SVG focus area two years ago and it got some interest but the feedback was that it was too big and unfocused. This year I want to try again with a more scoped proposal with specific areas we have reason to believe are significant pain points for devs. - Allow omission of fragment when using SVG <use> - Proposed last year: https://github.com/web-platform-tests/interop/issues/1045 , got 23 👍🏻 - Spec: https://w3c.github.io/svgwg/svg2-draft/linking.html#SVGFragmentIdentifiers - WPT: https://wpt.fyi/results/svg/struct/reftests/use-external-svg-resource-no-fragment-id.html - Support context-fill and context-stroke to make SVGs more easily themeable (reuse context colors in <marker> and <use> elements) - WPT: https://wpt.fyi/results/?label=experimental&label=master&aligned&q=feature%3Acontext-fill-stroke - Spec: https://w3c.github.io/svgwg/svg2-draft/painting.html - SVG filters - Proposed for Interop 25 https://github.com/web-platform-tests/interop/issues/756 got 52 👍🏻. - They allow devs to achieve a lot of effects that otherwise involve content duplication or using external images or JS. - Spec: https://drafts.csswg.org/filter-effects-1/ - WPT: https://wpt.fyi/results/css/filter-effects?label=master&label=experimental&aligned&q=%21backdrop-filter - getPathData()/setPathData()/getPathSegmentAtLength()/SVGPathElement - These grant web developers working with SVG paths a programmatic way to inspect or manipulate individual path segments. Today devs rely on polyfills for this, like this one that has 130 stars: https://github.com/jarek-foksa/path-data-polyfill. The crbug asking for this has positive dev feedback and 44 +1s. - Spec: https://w3c.github.io/svgwg/specs/paths/#DOMInterfaces - WPT: https://wpt.fyi/results/svg/path/interfaces?label=experimental&label=master&aligned
Trusted Types enable writing web applications that are free from DOM-Based Cross-Site-Scripting (XSS), the most prevalent web application vulnerability. DOM-Based XSS occurs when attacker-controlled values reach certain Web API functions, like Element.innerHTML which causes the execution of the attacker's JavaScript code. This pattern is common, especially in larger applications, and detecting it requires complex interprocedural data flow tracking in a dynamic language ( a[b] = c might actually be a vulnerability). Before Trusted Types adoption at Google, DOM-Based XSS accounted for >%50 of XSS reported to Google VRP. Trusted Types lock down those execution sinks to only accept values that were created securely; either because they are https://github.com/w3c/trusted-types/issues/347 or because they were created through author-created https://github.com/w3c/trusted-types/issues/347. One can also create a default, catch-all policy, e.g. to sanitize HTML or programmatically control where the scripts can be loaded from. The lockdown is controlled via CSP, which enables breakage-free rollouts with report-only mode, and gradual, backwards-compatible code migration - using the new APIs without locking down the execution sinks. In fact, about 60% of pages rendered by Chrome globally already use Trusted Types, likely via inclusion of Alphabet's libraries, whereas around 14% of the traffic enforces Trusted Types via CSP. Altogether, Trusted Types enable both writing new applications that are XSS-free, and eliminating DOM-Based XSS from existing applications, with a track record from Microsoft, Meta and Alphabet adoptions. As a data point, Alphabet applications migrated to Trusted Types have 0 reported XSS against them and we only see these bugs in applications not yet migrated, which is a significant reduction. In 2018 Google VRP rewarded $360K for all XSSes, in 2022 it was $95K. Since 2023, Trusted Types is being upstreamed into HTML. Interop 2026, 2025, and 2024 proposals: https://github.com/web-platform-tests/interop/issues/1138, https://github.com/web-platform-tests/interop/issues/800, https://github.com/web-platform-tests/interop/issues/500 cc: @otherdaniel
Newly Available
After recieving 82 👍 12 ❤️ and 9 🚀 emojis from last year's interop proposal (#1011), I'm once again asking for Reference Target to be considered for Interop 2027. It solves (and doesn't solve) some long standing issues with cross-root associations as outlined in the Edge Demo for Reference Target. - Reference Target has an Intent to Ship in Chromium 152 - All browsers have an implementation with passing tests behind a flag (WPT.fyi) - There's a community attempt at polyfilling the behavior: https://westbrook.github.io/reference-target-polyfill/ While I personally wish that "Attribute forwarding" as called out in the Edge demo could be reconsidered, I think anything we could do to solve this gap would be a huge leap forward in component authoring.
As the web's native combobox, <input list> combined with <datalist> behaves inconsistently across browser engines and platforms. All modern browsers implement <datalist>, minus a few areas of support on Firefox, but vary in styling and behavior. The proposed scope for this investigation: * Popup rendering * Styling and positioning consistency * Desktop and mobile keyboard-suggestions displays * Filtering behavior * How options are filtered against value * Case matching differences * Display consistency when <option> text and value differ * Affordance styling (the popup indicator icon) * Does this follow same convention of <select>? * Browser engine consistency * Working as more than a text box * Options availability in landscape mode * Mobile landscape behavior * A11y - roles and names as exposed to screen readers, keyboard navigation, escape behavior, and voice-control * A11y - Page Zoom and text styling in popup * A11y - AT inconsistencies