Authoritative list of features

[foolip]

I would like an @webref/features package which defines all the high-level features of the web platform, so that BCD could be grouped according to those features. Each feature would have a name and one or more spec links. For example, "Server Sent Events" is defined by https://html.spec.whatwg.org/#server-sent-events and the EventSource interface would be grouped under this feature.

I believe this would also be useful for MDN, which already has a feature hierarchy one could take inspiration from.

[foolip]

@dontcallmedom @tidoust we talked about this in a call last week. What do you think a concrete start to this list would look like, do we just create a JSON file and release it as @webref/features?

[foolip]

I took a look at the caniuse feature set and made a gist of the 500+ features currently in there:
https://gist.github.com/foolip/daa62983c8c97d979fa2f4159c5692e9

[jgraham]

Can the caniuse featureset be used directly, or what's the motivation for inventing something new (I can imagine several plausible reasons, but I don't know why others landed on the approach suggested here)?

[tidoust]

I think the whole purpose of this exploration is to converge on one list of features and understand how it can map to the implementation information that exists on the different status platforms. One core problem I see is that we may need to talk about features that are at different granularity levels.

Some figures, quickly looking at sources:

• bcd defines 13717 features
• Can I use defines 529 features
• chrome platform status defines 2153 features
• webkit status defines 154 features (102 "specs", 52 "features")

Trying to map these "features" to the list of specs we maintain in browser-specs, I end up with:

• bcd: 8941/13717 features can be mapped to 318 known specs
• Can I use: 384/529 features can be mapped to 148 known specs and ~100 of these features cover an entire spec
• Chrome platform status: 1328/2153 features can be mapped to 267 known specs and ~100 of these features cover an entire spec
• Webkit status: 120/154 features can be mapped to 84 known specs and ~65 of these features cover an entire spec

These mappings are currently maintained in the browser-statuses project (incidentally, this project also defines a list of ~100 features under the spec level, list that was used to write roadmap documents).

[foolip]

Can the caniuse featureset be used directly, or what's the motivation for inventing something new (I can imagine several plausible reasons, but I don't know why others landed on the approach suggested here)?

The caniuse set of features is the closest to the granularity of feature that I had in mind, so if there's any data set that could be transformed into a complete-ish list of features, it's this one.

But the main reason that my first impulse was a new list of features is that I was thinking of this as a way of linking features in BCD, caniuse, chromestatus.com, etc., and my assumption was that some entries in caniuse.com would be messy and at an unusual granularity. It's actually hard to find examples that are very problematic, but there is a wide range of granularity, from the very narrow promise-finally (single method) to the very wide svg (huge feature).

Since caniuse now includes all BCD entries as well there are also features that never get added to caniuse, IdleDetector is such a case right now.

But I'm not sure if starting a new thing is in fact the best approach, another could be caniuse with manual fixes, perhaps.

[tidoust]

Discussions here and elsewhere led to the web-features project within the WebDX Community Group. I'm closing this issue accordingly.