Map web-features to BCD, caniuse, chromestatus, etc.

[foolip]

We need a mapping to BCD in order to determine feature support status along the lines of https://github.com/ddbeck/common-web-feature-mockup.

The use case for links to caniuse and chromestatus isn't as clear, but could at minimum be used to check for consistency in browser support data in the different sources.

[foolip]

@ddbeck where do you think we should store the eventual compat data for high-level features? If it's in BCD, then BCD itself is probably a better place to list the constituent features, right?

[foolip]

I threw together caniuse links in #19.

[ddbeck]

Late last year, Philip and I had a discussion about what the mapping to BCD might look like. To briefly recap our discussion:

• For ease of iteration and development, the map from feature to BCD will live in this repo, to help cement structure, naming conventions, etc. I don't think either of us felt a commitment to having that data live here forever, though.
• To control scope, the web-features package won't include actual compat data from BCD. The package will publish a list of features, but it won't roll up compat data.

I'll also add that I think there remains some unknowns about what makes up a feature definition, if we come to rely on things that are outside the web-features package. For example, if web-features points toward caniuse and BCD, then how do we know when differences are bugs in those sources (e.g., bad data or bad mappings) and when differences represent feature divergence (e.g., two things share a name that describe different things)? Something to explore going forward.

[foolip]

@ddbeck a good starting point would be porting over the BCD mapping from https://github.com/ddbeck/common-web-feature-mockup/tree/main/web-platform-features, but not including that in the web-features package for now.

[foolip]

I'll also add that I think there remains some unknowns about what makes up a feature definition, if we come to rely on things that are outside the web-features package. For example, if web-features points toward caniuse and BCD, then how do we know when differences are bugs in those sources (e.g., bad data or bad mappings) and when differences represent feature divergence (e.g., two things share a name that describe different things)? Something to explore going forward.

This is an interesting question. I'm inclined to say that if the features aren't the same, then they shouldn't be linked, even if they have the same name. However, hopefully one is a subset of the other, and maybe we could have something like "ghost" features that match the definitions used elsewhere.

[foolip]

BCD and caniuse are happening in web-features, and we have a plan to use web-features identifiers in chromestatus. Nothing more is needed here.