Represent parent/child class relationship in IDL somehow.

[jpmedley]

We currently have a few base classes that are not instantiable. Examples include BaseAudioContext and Sensor, and it's probable that we will have more in the future. This introduces a number of problems:

• Linter rules that are valid for other interfaces can produce false errors.
• Displays of data from the child interfaces are missing items on the parent.

Perhaps the relationship should be captured somehow in the BCD itself. Not only would this provide a consistent and valid hook for alternate linting behavior, it would also allow consumers of the data to show information about parent classes.

[foolip]

Would a simple extends attribute work for this?

[jpmedley]

I think it would.

Is there any reason we'd need to know an interface's children as well? Maybe we cross that bridge when we come to it. We'll have a use case in front of us then.

[foolip]

You can find the children by parsing all of the JSON files, so leaving that until it's needed seems fine.

[foolip]

If we had this information in BCD, would it be used to show inherited members? For an interface like HTMLLinkElement with a lot of big ancestor interfaces and just a few members, how would this look like in practice?

[saschanaz]

TIL there already is inheritance data in another repository: https://github.com/mdn/data/blob/master/api/inheritance.json

Could we merge the data into BCD?

[queengooborg]

I'm planning to merge some of the data from mdn/data over to BCD to de-duplicate, so this is on my agenda!

[caugner]

For what it's worth, the related PR was closed in August 2023:

We should get the data directly from webref and not copy anything into BCD or into content.