Classifying types of features

[Elchi3]

In #3420 @jpmedley says:

Instead of doing "*eventname*_event" for the slug, might it be better to have an attribute hanging off of it that specifies its type (event, property, method, etc..). (This would also replace the description now used for constructors.) Then in every case, not just events, I could write code like the following, which would return every property from a given interface:

function getProperties() {
  return bcd.api.Widget.filter(branch => {
    return branch.type === 'property';
  }
}

Currently, BCD stores features in hierarchies that data consumers can walk down.
"api.SpeechSynthesis" gets you things we've installed under that tree.
Beneath it you can find constructors, properties, methods, events and other types of features for this interface or object (the root tree isn't really classified either, but at least we're hopefully getting rid of mixins there).

In the CSS tree this is similar, you have trees like "css.properties" or "css.at-rules" with the expectation that you'll find web platform features of that kind underneath these trees. This works well, but isn't perfect, so additional data is needed to make the data more machine-readable further down in these trees (see #3366).

I'm opening this issue to discuss how we could classify compat data we have in the api/ folder better so that data consumer can work with them best.

A first idea by Joe is to add a "type" property to a feature branch, so that you can filter features as shown in his code snippet.

[jpmedley]

By the way, I'm not an engineer, so I don't plan to go all out defending my particular proposal. What I do support is the idea of having classification of some kind in the data.

[jpmedley]

This would also give us an easy way to add "()" to autogenerated links in compat tables.

[foolip]

@queengooborg and I have talked about this, it would be quite useful. Currently this information can be partly derived by also parsing a bunch of Web IDL and pairing up BCD entries with IDL definitions, but it's not straightforward.

This came up in #7287, cc @saschanaz too.

I imagine this might be helpful for #472 too, for any solution short of deleting all mixin data.

One thing that makes me hesitate, however, is that there's a lot more type information that can be derived from Web IDL than we're plausibly going to include in BCD, like all the return type and argument types of methods, whether an attribute is readonly, and so on. I'm not certain that there are data consumers who would have a lot of use of a small subset of this data. An alternative could be to instead make sure that w3c/webref#68 + https://github.com/GooborgStudios/mdn-bcd-collector/tree/main/custom-idl span everything in BCD, and for data consumers to combine that with BCD themselves.

#6571 is related to this too, as knowing the interface hierarchy and which methods/attributes/etc. use certain interfaces would allow us to lint for more consistency of the data.