Consider extracts per IDL fragment with the "full" interface

[tidoust]

See discussion in https://github.com/w3c/respec/issues/3264

As noted there, the information about partial interfaces defined in a given spec is already available in idlparsed extracts under the idlExtendedNames property. It is relatively easy to build a view per interface that agglomerates base and partial (and mixin) definitions. One still needs to parse all extracts to build that view.

To avoid putting the burden on authoring tools, and since the information could also be useful for other types of tools (e.g. type annotation tools), it may be useful to build these views directly as extracts.

For each IDL fragment, we could annotate and merge the info in idlparsed to a common JSON structure so that one may serialize that info into whatever format needed. It may also be useful to also include a textual rendering of the full interface as if it were defined in a single Web IDL block.

It probably does not make sense to generate an HTML representation because most tools would probably want to tweak that representation to their liking in any case.

[tidoust]

Notes on follow-up discussion:

• Integration in WebIDLPedia is good. Next steps there are to reuse the webidl2.js writer to serialize the structures, add links to specs and generate a full representation of IDL names
• Producing a view per IDL name in Webref still seems useful for other tools (and WebIDLPedia) to create:
  1. A JSON representation of the parsed IDL for the IDL name that encompasses inherited classes, mixins, and partial interfaces. This would be used by WebIDLPedia directly, and seems useful for other tools. Note that this means that structures such as EventTarget will be repeated in many JSON files but that seems fine. The JSON files could be created under an idlnamesparsed folder.
  2. A textual definition of the full interface as a set of WebIDL blocks. That definition would not include the definitions of the inherited classes and included mixins. It would also not attempt to merge the WebIDL blocks to create a full definition. The goal of this extract is more to have an easy way to follow the evolutions of a given interface over time. The .idl files could be created under an idlnames folder.

In both cases, we will have to come up with a rule to order partial definitions. Something like: base definition first, WebIDL parser AST order when a name appears multiple times in a given spec, and order of the specs in browser-specs.