Web features, Baseline status, and standardization signals

[tidoust]

Session description

How do web developers talk about web features? What names do they use? How do these features map to specifications, fine-grained API functions and tests? What does a developer view tell us about the interoperability of the web platform?

The web-features project, envisioned in 2022 and launched in 2023, explores the set of interoperable features of the web platform by:

• Creating feature definitions, which identify and describe capabilities of web browsers.
• Generating Baseline support data, which summarizes the availability of web features across key browsers and releases.
• Publishing the web-features npm package, which bundles feature identifiers with Baseline statuses.

Developed by the WebDX Community Group and contributors, web-features data leverages compatibility data from the browser-compat-data project, is already integrated in MDN, Can I Use, Web Platform Tests, and is starting to reach additional authors of JavaScript libraries and dashboards.

Looking forward, feature identifiers at the "right" level make it possible to tag signals from the web community in surveys, browser standard positions, bug trackers, polyfills and usage counters. It also makes it easier to combine these signals with other projects that generate data out of specifications such as browser-specs and webref.

Features are also used in standardization groups, informally to organize discussions, but also formally to address transition requirements set forth by the W3C Process Document for advancing specifications on the Recommendation track. Within the Process, new features are defined as substantive changes that add new functionality, and used to assess implementation experience, document functionality that is considered at risk, and scope changes that may be incorporated in a specification depending on its maturity stage. This raises questions on the intersection between web-features and W3C’s standardization process, including:

• Can web-features provide useful information to working groups?
• Can it also inform the standardization process, e.g., to detect the need to transition a feature implemented by more than one browser out of incubation?
• What additional data or tooling would make web-features a powerful tool for standards bodies?
• How would you like to see web-features data presented in standards work?

Session goal

Share updates on the web-features project, its use to inform the standardization process, and additional data, tooling and visualizations to make web-features a powerful tool for standards bodies.

Session type

Breakout (Default)

Additional session chairs (Optional)

@captainbrosset, @atopal

IRC channel (Optional)

#web-features

Other sessions where we should avoid scheduling conflicts (Optional)

No response

Instructions for meeting planners (Optional)

No response

Agenda (link or inline) (Optional)

• Presentation (20mn - see slides)
  • Web developers and web features
  • Web features and standardization
  • First stab at gathering signals to inform standardization process
    • Late incubations
    • Late Working Drafts
    • Not-so-well supported Recommendations
• Discussion (30mn)

Link to calendar (Optional)

Calendar entry

Meeting materials (Optional)

• Minutes

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular. Bots and W3C meeting organizers may also update the description, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C meeting organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.

[tidoust]

Main outcomes of the discussion:

• The Baseline status is meant to capture a developers' perspective. That is aspirational as it is hard to capture (or sometimes even measure) how a developer sees implementations. One example is quality of implementation (performance, UX). Another example is integration with assistive technologies. Extending BCD data is always possible... but it comes with a cost (resources, reliable sources of data needed, etc.)
• Collecting app-centric developer signals to complete the information would be useful. This probably requires additional developer research, such as some sort of State of Progress Web Apps (PWA) survey.
• If you're involved in an incubation or working draft, you usually know the status and details. A more general dashboard would allow to go beyond those directly involved, to make sure we keep ourselves (W3C) accountable. Some groups tend to transition to Candidate Recommendation later than when they could.
• It is not yet clear who would review such a dashboard, but having the infrastructure to emit the signals seems a good idea.
• Next step is to automate and integrate the exploration somewhere visible.
• Discussions continue in the WebDX Community Group