W3C

– DRAFT –
Curating the web platform's data and documentation

25 September 2024

Attendees

Present
Anssi_Kostiainen, emeyer, estelle, kbabbitt, miriam, moonira, Niklas, oriol, past, petele, queengooborg, rachelandrew, TabAtkins, tidoust, ydaniv
Regrets
-
Chair
Estelle Weyl, Florian Scholz, Vinyl Da.i'gyu-Kazotetsu, wbamberg
Scribe
tidoust, estelle, emeyer

Meeting minutes

<estelle> +1

fscholz: I'll go through some slides first.
… We're Open Web Docs, non-profit with sponsors, thank to them!
… We work on repositories that you may or may not be familiar with.
… browser-specs, webref, mdn-bcd-collector, browser-compat-data, web-features and content
… These repositories make up a lot of data available in documentation.

fscholz: It all starts with browser-specs.
… The list of specs is not only from W3C, also IETF, WHATWG, CGS, TC39 and so on.
… Currently, it has 662 specs.
… We are reading these specs to document them in a centralized place!
… browser-specs has this notion of standing. "good", "pending" or "discontinued". You could say that there are 619 "good" specs.
… From these 619 specs, we have a lot of web platform features, incl. IDL interfaces, CSS properties, HTML elements, et.
… Our entry on getting data from these specifications is the webref project.
… It does contain a lot of data, but it does not extract a few others, such as HTTP headers or WebDriver endpoints.
… webref is the way we can figure out what is available on the web platform.
… In particular, we have the mdn-bcd-collector project, that checks what's actually implemented in browsers.
… We get a list of "features" from webref (IDL interfaces, methods/properties/events, CSS properties) and run through them in browsers: about 17880 features.

fscholz: The collector looks at what is actually implemented and feeds that into the BCD project.
… It only records features that are implemented in at least one browser.

<queengooborg> * it = BCD

fscholz: We land at 15620 features that have seen at least one implementation.
… BCD is a more than what the collector collects.
… Now, what the previous breakout session discussed is web-features, which maps these thousands of features to catalog features and calculate baseline status.
… Throwing a bunch of numbers at you, we end up with 7440 baseline features (widely available).
… These features are what users can actually use.

fscholz: Someone in our community made a Venn diagram out of it.
… But then, availability does not tell us anything about feature adoption.
… There is no consistent use counters in browsers, which I find surprising. I would love if there were some data about how much features are used.
… There are some work in the State of XX surveys.
… We're monitoring the specs, collecting the data, and documenting the feature in MDN. I wonder what more we can do so that more features end up in a sweet spot.

fscholz: Any feedback on the process? Things to improve in any of these projects? How to get more features through this process successfully?
… Also, answering "what is the web platform" in terms of features is hard. The numbers I have on the slides are from this week. They will be different next week.
… Things will evolve, it would be nice if the velocity of features that make it to browsers would go up.
… So many specified features in the specifications, but only half of them make it through.

past: Is the number of baseline features complete or an estimation?

fscholz: There's a package that computes the baseline status automatically for BCD keys, but the features here are not web-features.

kadirtopal: These are BCD keys, not features. The ratio is roughly one to 10. One web-feature for 10 BCD keys.

<kadirtopal> tidoust: saying that many features are not baseline need to consider that a lot of those features are in incubation.

tidoust> the number of baseline features is missing the incubation stage features, so it's normal that they are not yet baseline.

tidoust> oops

kadirtopal: Re. tracking usage of features, there's still work going on to connect usage counters to web-features. We're doing it the other way round, from usage counters to web-features.

jgraham: I don't think the goal is just shipping new features irrespective of what these features are.
… There are likely different opinions in the room, different standard positions about features.

fscholz: Yes, my point is that a lot of work goes into specifying and maintaing features and data, so you'd like things to be successful. Not necessarily about doing more things.

jgraham: For example, we found that use counters are less useful than you might think. Some features are not intrinsically used because they only apply in specific contexts, e.g., WebRTC.
… You need a lot of context to understand the figures.

kadirtopal: Those things that are one browser only, how do they distribute over years? Is it getting better? Or worse? It would be interesting to compute that information.

Review and clarify spec selection criteria in browser-specs

tidoust: [adding specs in browser-specs sometimes feels like rolling dice]

estelle: [scribe missed]

past: The purpose of MDN should be to document every possible way for developers to build their web site on the web today. It could be that they are targeting a specific context, in one particular browser on one particular form factor.

Rick Viscomi from Google leads the annual web almanac, we could feed him the list of the 7K+ features or otherwise access his automation tests to test what features are being used and how popular/common they are

fscholz: To be clear, the point in time when we document features in MDN is when they ship in at least one browser. That hasn't changed over the years.

https://almanac.httparchive.org/en/2022/

past: The numbers are not clear between the second and third numbers, 17880 and 15620.

fscholz: That's where we filter out features that are not yet in one browser

queengooborg: A mixed bag of features, we may also remove deprecated features. Features that have landed in a spec but are never implemented.

tidoust: We try to have specs in good standing
… For consistency reason, we have to force a spec standing to be "good" because it gets referenced by other specs
… Part of the guarantee with the data is that it’s consistent and makes sense as a whole
… So sometimes we have to force spec status

tidoust: We may end up forcing a spec in good standing in browser-specs because its IDL starts to be referenced by another spec, for consistency.

fscholz: Every new feature needs to be documented, please keep that in mind :)

past: The number of tutorials in MDN could be an interesting metric to track as well.

<Zakim> past, you wanted to react to past

fscholz: Web-features could actually help with that. Less fine-grained, so we should end up with 10 times fewer entry points.

kadirtopal: It should be easy to identify which features have tutorials and how-tos in the end.
… Re. compat data in browsers that are not main them. How are we currently maintaining them?

fscholz: Done through the concept of mirroring. Opera is Chrome from a few versions back. The Opera data is not that well maintained.
… For other browsers, it's more complex than this.

kadirtopal: Do you have a backlog of what you still need to process?

estelle: Last time I checked it was about 1200.

fscholz: Some large APIs that remain, e.g., WebNN.

<Zakim> queengooborg, you wanted to react to kadirtopal

<fscholz> https://openwebdocs.github.io/web-docs-backlog/

queengooborg: I still run the collector on Opera. If it's supported, we go through mirroring, if it's not, we flag it.

https://openwebdocs.github.io/web-docs-backlog/

tidoust: I wonder if there’s something we could do for HTTP headers and WebDrivers

fscholz: Our way in is webref; the more we can make things machine-readable through webref, the better

<queengooborg> Open issue about collecting WebDriver data through the collector: openwebdocs/mdn-bcd-collector#1762

fscholz: As you say, where would we put too much effort on the spec authors
… More HTTP headers would be nice
… I think it would be helpful for us so we can document more of them

493 widely available features are not yet documented (https://openwebdocs.github.io/web-docs-backlog/baseline/). 416 are SVG related. 27 are DOMMatrix related

fscholz: Webref has helped us to figure out what’s in every new browser release to see what’s new
… We used to rely on browser engineers to tell us

493 widely available features are not yet documented (https://openwebdocs.github.io/web-docs-backlog/baseline/).

fscholz: The machine-readableness of this is necessary; otherwise our efforts fail

<past> example of WebDriver info in a spec: https://webbluetoothcg.github.io/web-bluetooth/#automated-testing

tidoust: I can try looking into the HTTP headers thing

<queengooborg> tidoust: I can look into HTTP headers for webref

fscholz: I also have Henrik from Mozilla looking into the WebDriver stuff

fscholz: Okay, I think that’s it; come find me for OWD stickers

Minutes manually created (not a transcript), formatted by scribe.perl version 229 (Thu Jul 25 08:38:54 2024 UTC).

Diagnostics

Succeeded: s/about 200/about 1200/

Maybe present: fscholz, jgraham, kadirtopal

All speakers: estelle, fscholz, jgraham, kadirtopal, past, queengooborg, tidoust

Active on IRC: anssik, emeyer, estelle, fscholz, jgraham, kadirtopal, kbabbitt, miriam, moonira, Niklas, oriol, past, petele, queengooborg, rachelandrew, TabAtkins, tidoust, tpac-breakout-bot, ydaniv