Visualize web-features

[captainbrosset]

Originally proposed by @Shinigami92 here: #536 (comment)

https://github.com/web-platform-dx/web-features/tree/main/feature-group-definitions looks like something I should explore 🤔
Right know I miss explorability on MDN docs [...] maybe I could write a tabular application to make these yaml data visually presented (and search-/filterable) on one site with links to their sources.

The web-features repo is still early in the making, and doesn't contain a lot of features, but once the process is in place and more features get tagged in BCD, I expect the number of features to grow.
Also, at some point, we'll start defining relationships between features (i.e. feature groups).

I believe this presents a really interesting opportunity to build a visualization for the data in the repo, in such a way that users can explore the web platform as a hierarchical list of features, and discover which ones they could use.

[captainbrosset]

@Shinigami92 the WebDX CG quickly discussed about this yesterday. We really love the work you've done so far.
Please feel free to report any feedback you have about the data in this issue. Working on this visualizer tool, you're one of our first consumers, and any feedback you have will be very useful to us.

[Shinigami92]

So based on this definition: https://github.com/Shinigami92/baseline-green/blob/26a3c02cef37f0f03e58820d1469ff0ee12d7778/src/App.vue#L7-L27

1. I did not fully understand yet what baseline 'low' / 'high' exactly means.
2. If there is a baseline_low_date, what does it mean, and why is there no baseline_high_date?!
3. support could be mapped differently
   e.g.:

   support:
     chrome:
       desktop: number
       mobile: number
     firefox:
       desktop: number
       mobile: number
     ...

4. I would love to have links to the related MDN site
   Maybe even for each compat_features

[atopal]

1. Baseline low and high are indicators for how wide the support for a given feature is. "Low" starts from the moment a feature is supported in the last browser. "High" starts 2.5 years after "Low" and is a proxy for about 95% availability of that feature.

2. Features where the "low" date is less than 30 months (2.5 years) ago from today won't have a "high" date yet.

[captainbrosset]

4. I would love to have links to the related MDN site. Maybe even for each compat_features.

For this feedback specifically, I would suggest adding a dependency in your project to @mdn/browser-compat-data. This is the browser compat data that MDN and other sites like Can I Use leverage in their docs.

The web-features project depends a lot on the browser-compat-data (BCD) project.

For example in https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/async-await.yml:

compat_features:
  - javascript.builtins.AsyncFunction
  - javascript.builtins.AsyncFunction.AsyncFunction
  - javascript.operators.async_function
  - javascript.operators.await
  - javascript.statements.async_function

These strings are BCD keys. Each key correspond to an entry in the BCD data. For example javascript.statements.async_function can be found in https://github.com/mdn/browser-compat-data/blob/main/javascript/statements.json, which has a an mdn_url property you can use.

Now, the data of the web-features project is still not final, we're still working on it and, in particular, the way we refer to BCD is changing. For example: https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/edit-context.yml has no compat_features field. That's because its name: edit-context actually maps to a tag in the BCD project. In particular, it maps to the tag within this file: https://github.com/mdn/browser-compat-data/blob/main/api/EditContext.json.

So, as you process files in the web-features repo, you should remember to do two things (over time, you should only have to do one, but we haven't settled on the final way yet):

1. Look for compat_features in the YAML file and, if it's there, map the strings in it to BCD keys.
2. And, use the YAML file name as an ID to look for BCD files that contain the tag web-features:<the-id-here>.

Hope this helps.