[FEATURE REQUEST] Store support information in an internal table

[jpmedley]

Background

It's my understanding that browser support data is transferred to the output as it is encountered. This means that the only option for displaying support information is to list support for each member of an API beneath the heading that it applies to. This is by no means a bad thing. This limitation in how chrome-types processes support data limits the way it can be used by consumers of chrome-types.

One immediate consequence of this is an inability to render a single support table or information block for a single API. This means that a potential extension developer must review APIs member by member to determine if extensions can serve a particular use case. Although this is not necessarily a problem with older APIs, it may be critical to adoption of new APIs, since new API are almost always implemented in phases. Whether they are or not, enhancements and changes are made after new API designs meet real-world problems.

Rendering a single table would have been useful during the roll-out of MV3 by making it clear to developers that conversion to MV3 could begin for their particular use case. "What's new" and the extension Google group already attempt to serve this purpose. This doesn't just require developers to pay fastidious attention to these channels. When they don't, they must also do manual searches as they would with the information provided with each API member

Requested enhancement

Output support data in chrome-types as a single data structure or structures. This will make it easier to output such data in a single reference table such as those provided by MDN for web platform APIs. (Please don't make any assumptions about the design of reference tables in our docs. I've provided the MDN link as an aid to understanding the reason for this request, not as a proposal for a design.) Outputting support data in a single structure would also enable use cases we haven't thought of yet.

Alternatives considered

Hand curation

It should go without saying that hand curation is both prone to becoming out of sync with the generated source of truth, but also prone to human error during the copy work. [MDN](https://developer.mozilla.org/en-US/'s experience with this is illustrative. Years ago, MDN used hand curated browser compatibility tables. When they converted to JSON files involved parties realized the data was so bad that Googlers working on web platform tests were repurposed to autogenerate the data. This effort to clean up MDN's browser compatibility data started more than five years ago and is still under way.

Scraping the generated output

This would tightly couple a downstream client to its source in a way that could limit the ability to change chrome-types in the future.

[jpmedley]

Any thoughts on this?