Annotating WPT to Surface the Status of the Platform

## Annotating WPT to Surface the Status of the Platform

[W3C TPAC](https://www.w3.org/2025/11/TPAC), 2025-11-11

<p class="license">
  Except where noted, this presentation is licensed via
  <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">
  CC BY SA 4.0 <img alt="Creative Commons License" style="border-width:0" src="cc-by-sa-4.0.png"></a>
<p>

---

## Hello!

[Bocoup](https://bocoup.com), a worker-owned tech consultancy  
<img class="avatar" alt="A 16-bit rendering of the video game character Mega Man--the image Mike often uses as an avatar" src="megaman.png">[Mike Pennisi](https://mikepennisi.com) (he/him), a worker-owner

---

## Outline

I. Intro to web-features  
II. Crash-course in WPT test annotation  
III. Go forth and classify!  
IV. Discussion: what does it mean to fail this test?

---

## I. Intro to web-features

---

## I. Intro to web-features

### Motivation

**High level**: promote understanding of the web platform--both its scope and
its availability

**Practically speaking**: power
[MDN](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility),
[Can I Use](https://caniuse.com/), [webstatus.dev](https://webstatus.dev), and
[Baseline](https://web-platform-dx.github.io/web-features/) (among [many other
projects](https://web-platform-dx.github.io/web-features/baseline-in-the-wild/))

...for more, see "[web-features and
Baseline](https://www.youtube.com/watch?v=QzfwNFIXOkM)" [2025] (14min) by
Patrick Brosset
([slides](https://www.w3.org/2025/Talks/AC/web-features-patrick-brosset/))

Note:

- among developers - to increase confidence in commiting and to surface
  opportunities for advocacy
- among implementers - to prioritize effort

---

## I. Intro to web-features

### Status in test annotation

[Incorporated into Test262 as of November,
2025.](https://github.com/tc39/test262/pull/4599)

Initial coverage for WPT currently underway.

---

## II. Crash-course in WPT test annotation

---

## II. Crash-course in WPT test annotation

### Anatomy of a `WEB_FEATURES.YML` file

<small>[`css/css-values/WEB_FEATURES.yml`](https://github.com/web-platform-tests/wpt/blob/master/css/css-values/WEB_FEATURES.yml):</small>

```yml
# `.gitignore` semantics - https://git-scm.com/docs/gitignore
features:
- name: calc
  files:
  - calc-*
  - "!calc-infinity-*"
- name: calc-constants
  files:
  - calc-infinity-*
```

<small>[`mediasession/WEB_FEATURES.yml`](https://github.com/web-platform-tests/wpt/blob/master/mediasession/WEB_FEATURES.yml):</small>

```yml
features:
- name: media-session
  # The special value `"**"` means "all tests in this directory
  # and all subdirectories"
  files: "**"
```

Note:

The "files" property can be specified as a list of string values (where each
value is a "glob" pattern used to match against the files in the same
directory) or the string value `"**"`.

---

## II. Crash-course in WPT test annotation

### Considerations: cross-cutting tests

Designed for the sake of convenience

```html

<article aria-label="label" data-expectedlabel="label" data-testname="label valid on article element">x</article>
<aside aria-label="label" data-expectedlabel="label" data-testname="label valid on aside element">x</aside>
<blockquote aria-label="label" data-expectedlabel="label" data-testname="label valid on blockquote element">x</blockquote>
<button aria-label="label" data-expectedlabel="label" data-testname="label valid on button element">x</button>
<dl aria-label="label" data-expectedlabel="label" data-testname="label valid on dl element">

```

Designed due to necessity

```css
.test {
  border-radius: 10px;
  box-shadow: 0 0 0 10px;
  width: 40px; height: 40px;
}
```

Note:

When tests cover multiple features as a convenience to the test author, the
best solution is often to refactor the tests.

When tests explicitly verify the confluence of features, it's not always clear
whether failures can be attributed to one or more features.

For our initial work, we've prioritized building a partial definition with the
expectation that nuanced decisions can be made following future conversations
on a feature-by-feature basis.

---

## II. Crash-course in WPT test annotation

### Considerations: trade-offs to pattern matching

Strength: flexibility (e.g. `box-shadow-024.htm` or `comp_tooltip.tentative.html`)

Weakness: unintentional matching

Note:

Pattern matching allows classifiers to be resilient to expected changes in
directory contents. This often occurs when file names have predictable file
names regarding their intent, membership in a sequence, or tentative status.

On the other hand, new contributions can unintentionally match existing
classifiers. In the best case, contributors recognize these situations and take
on the extra effort to preserve accuracy. In the worst case, the mistake goes
unnoticed, degrading the quality of the classifier.

---

## III. Go forth and classify!

- author tests to support classification (and ideally, verify their classification)
- update tests to improve classifiability
- [prototype](https://web-platform-tests.org/writing-tests/file-names.html) new
  features directly in WPT via `WEB_FEATURES.tentative.yml`
- [propose new features to the CG](https://github.com/web-platform-dx/web-features/blob/main/docs/CONTRIBUTING.md)

---

## VI. Brainstorming

---

## VI. Brainstorming

### How do we promote maintenance?

![An automated pull request to the web-features repository](web-features-pull-request.png)

Source: https://github.com/web-platform-dx/web-features/issues/3399

Note:

Current solution: scheduled task in external repository periodically alerts
the maintainers of the web-features project.

In the current solution, contributors and reviewers may be unaware of the
impact that a given patch has on the web-features project.

---

## VI. Brainstorming

### How do we promote maintenance?

Perhaps a task in WPT could immediately alert contributors & reviewers, e.g.

- X changes to web-features classifications
  - X new tests unclassified
  - X new tests classified
  - X existing tests classification changed

---

## VI. Brainstorming

### What does it mean to fail this test?

```html
<script>
test_interpolation({
  property: 'text-shadow',
  from: neutralKeyframe,
  to: 'green 20px 20px 20px',
}, [
  {at: -0.3, expect: 'rgb(255, 176, 0) 7px 33px 7px'},
  {at: 0, expect: 'rgb(255, 165, 0) 10px 30px 10px'},
  {at: 0.3, expect: 'rgb(179, 154, 0) 13px 27px 13px'},
  {at: 0.6, expect: 'rgb(102, 143, 0) 16px 24px 16px'},
  {at: 1, expect: 'rgb(0, 128, 0) 20px 20px 20px'},
  {at: 1.5, expect: 'rgb(0, 110, 0) 25px 15px 25px'},
]);
</script>
```

Note:

When a test for the interaction of features fails, it may not reflect a lack of
support for both. Consider a browser fully supports CSS animations but does not
yet support text-shadow. When it fails a test for animating a shadow, should
that impact its support metrics for animation? Is there room for nuance in the
way feature support can be reported? And if so, what changes might be needed to
the classification schema?

---

## Thanks!

<img class="avatar" alt="A 16-bit rendering of the video game character Mega Man--the image Mike often uses as an avatar" src="megaman.png">Mike Pennisi (he/him), [mike@bocoup.com](mailto:mike@bocoup.com)