Meeting minutes
<marie> https://
Slideset: https://
Patrick: Co-chair of the WebDX CG with François. I plan to present the web-features project, what we're doing, why, and where we're going from there.
… [going through logistics and rules]
Patrick: WebDX is a CG. Two focuses to improve the overall developer experience of the web platform.
… First focus is coordinating research efforts. Second focus is building a shared description of the web platform.
… Today's focus is number two. But research covers State of surveys, that help inject priorities into Interop.
… If you're a developer, please continue taking these surveys!
… If you're on a browser team, please come with questions that you'd like developers to answer!
Patrick: To build a shared description of the platform, we're creating a catalog, web-features, of features.
… The second thing we're doing is the Baseline definition.
… The web-features repository contains
… a thousand features that make sense from the perspective of a web developer.
Patrick: The features maps to BCD keys. BCD is at a finer-grained level. That's very useful but not the level that developers talk about.
… At the other end, there's more Can I Use that is sometimes too large.
… Each feature gets a unique ID that is used throughout the entire ecosystem.
… Some features are small, others are bigger, sometimes because they've been there for a long time.
… It's really meant to be a living catalog.
… Not a fixed set of features. Deprecated features are identified, new ones get added.
… Features can be merged.
Patrick: That brings me to Baseline. It's a simplified implementation status. Simplified because it only has 3 states, and because it only covers implementation in a core browser set.
… Newly available means features is available across browsers. Widely available is the same thing, plus has been available across browsers for at least 30 months. Not going into details here.
Patrick: We're nearly feature complete!
… The most crucial source of data we're using is BCD, a semi-automated data source that tells us when fine-grained keys are supported on a browser.
… We also compare ourselves with Can I Use to make sure that we're going in the right direction.
Patrick: The blue line on that chart is the number of BCD keys, slowly evolving over time. The red line is how much of that we cover. We started early 2024 with about 1000 keys mapped and we ended the year with about 90% keys mapped.
… That's thanks to Google injecting resources, many thanks!
… It takes time for people to maintain this and grow the collection. We need help! Please check the repository.
… The last remaining keys are mainly composed of deprecated or old features that are more difficult to map or lower priority.
Patrick: You can contribute, and we'd welcome that!
Patrick: What can we do with the data? I'll talk about how the data is connected with other data sources. Which consumers already use the data today. And how you could.
Patrick: Web-features is trying to be a reference dataset, so that many other data sources can link to them through their unique IDs.
… We map to BCD, but BCD also maps to our feature IDs. Same thing with MDN pages.
… Web Platform Tests also point to web-features IDs. WPT also makes Interop possible, and Interop areas can be mapped to feature IDs as well.
… Bug trackers come to mind as well, making it easier to compile a "behind the scenes" story.
… Much of that is already mapped. I very much like this idea that a graph like this can make developers realize how the sausage is made.
… They can then more easily follow along how things evolve.
Patrick: Existing consumers of the data include MDN, Can I Use, Can I WebView. We're seeing more and more dashboards as well, we maintain one.
… Google has one, we know of a third-party one. The data is useful by itself, so we're seeing it used more and more.
… Tools also start integrating the dataset, including in ESLint, VSCode, RUMVision and RUM Archive Insights.
… Very useful stuff!
Patrick: Quick example of our explorer.
… Left side shows a feature that has limited availability. You can follow links to bugs or standard positions, surveys that talk about this feature.
Patrick: If you want to use the data yourself, you may use npm to retrieve the data.
… We also have a compute-baseline package, more fine-grained, not going into details.
… We also maintain a web component for baseline status.
Patrick: How do we communicate about Baseline?
… Baseline is a trademark owned by Google.
… Baseline is not a final answer.
… A yes or no answer is very rare. Baseline looks like a yes/no answer, but it's not. It does not take everything into consideration.
… For example, there are other browsers not taken into account. Accessibility support is not accounted for either.
… It does not take into account if a feature can be progressively enhanced or can be polyfilled or you have a fallback.
… Don't treat baseline as Yes/No!
Patrick: We have a roadmap for 2025. We want to add missing features, include discouraged features. We want to continue to integrate new features as they get prototyped as well, including very early features, so that they get a unique ID early on.
… That means we need a flexible story to redirect people from an old name to a new name.
… Another thing is that we want to help more tooling providers integrate with the data.
Patrick: Last slide is all about conversation starters :)
<marie> Conversation starters:
<marie> Ensuring web-features and Baseline align with web devs needs.
<marie> Extend Baseline to additional contexts, such as WebViews.
<marie> Unify the deprecation concept (terminology, expectations).
<marie> Connect other data sources.
<marie> Latest issues on the repo:
<marie> Improving communication about Baseline (#2783)
<marie> Consider taking progressive enhancements into account for the Baseline status (#2758)
Patrick: How do we evolve Baseline, integrate with additional contexts, etc.
Discussion
<Zakim> Mike, you wanted to comment
Mike: Speaking as contributor to Ladybird and to existing browser engines. Before I started to contribute to this new engine, interoperability data meant something different for me. Baseline is rightly focused on developers. At the same time, you also have browser projects trying to make priority decisions.
… For Ladybird, you go to a certain site that you want to use, and it breaks. The reason it breaks is that the underlying feature is not implemented.
… A core example is Service Workers for now. I keep bumping into sites that break due to Service Workers not supported. Or down the line Media Source Extensions.
… All of these are pretty fundamental. But there is a much longer tail of things where things work to some degree but it might surprise you what's not supported. With CSS, there are so many features around that it's hard to figure out which one is causing the web site to break.
… When making priority decisions, trying to get a read on most used features is useful.
… It would be good for less mature browser engines like Ladybird, Servo to have a way to more systematically know which features are widely used and, if not implemented, are going to significantly break the user experience.
martin: Relates to previous discussion on profiling the web. Perhaps this is the need we have. What we will need to cover this particular type of applications is a kind of guideline of which features need to be supported.
… Baseline could be interesting for WebView implementors for example.
… I see topics as being related. In this case, we don't want to re-invent the web.
Patrick: web-features is the data. There are many ways it could be organized. Baseline is just one view of the data. No reason why other views couldn't be useful!
kadirtopal: It makes sense to me. Regarding usage, that's one of the things that webstatus.dev should fairly soon have as we're asking Chromium to connect use counters to web-features IDs. That would provide some insight on usage. Of course, that's going to be specific to Chrome usage, but that should be representative of the web as a whole.
<simon> kadirtopal: Is "the other part" to actually track the features use per site?
martin: I wish I had this Baseline thing in the past. I got a lot of questions 15 years ago in the Spanish W3C office. Should I use this new feature? It was always difficult to find a real answer and/or commitments that the features would be implemented.
… It's good to see data on underlying features. Very useful for decision making.
Patrick: Thank you for the feedback. Widely available status has been very useful to tell developers that features can be used. Many devs wait a long long time before they start remembering about a feature that started to ship long time ago.
… We also want to add nuances. Baseline de facto simplifies things, but the web is far more being a simple platform, and the context is important.
<marie> thanks Patrick and François !!
<Patrick> Thanks everyone
Patrick: Feel free to join the WebDX CG, check the mailing-list and GitHub repositories!
<tidoust> i/… [going through logistics and rules]/[slide 2]