Standard data format for sharing compatibility tables

[zachleat]

A standard (probably JSON) data format to allow developers to easily consume and build/IDE tooling around different compatibility tables for webdev features.

Perhaps eventually this would allow third parties to submit data sets to be consumed and shown in caniuse.com or with an alternative compatibility table search UI.

Data sets might be published for easier consumption on npm.

Data sets:

• https://github.com/fyrd/caniuse
• http://kangax.github.io/compat-table/
• individual docs pages on https://developer.mozilla.org/en-US/
• http://fontfamily.io/
• http://stateofwebtype.com/

etc, etc. See more on: https://www.zachleat.com/web/compatibility/

[nhoizey]

There's a project on MDN for this, but I don't know the details, or if anything about this is public yet.

Maybe @JeremiePat can give some informations.

[JeremiePat]

Hi!

Yes, MDN is in the process of outsourcing its full set of browser compatibility data (help welcome) in a JSON format to make it consumable by various tools (so far MDN but we are actively looking for support through IDE)

See: https://github.com/mdn/browser-compat-data/

MDN is also releasing other data and yes they intent to publish it on npm:

• https://github.com/mdn/data
• https://www.npmjs.com/~mdn

[dstorey]

For large parts of the web platform (not so much CSS or pure ES) WebIDL is the source of truth for this. Edge uses it to generate code, and I believe other browsers do too.

One of the things I'd love to do is to use each browser's WebIDL to generate compat info automatically rather than have it manually curated (which often ends up wrong or out of date.

[chicoxyzzy]

Hi! I'm one of compat-table co-maintainers. I would love to discuss if and how could we join forces.

[JeremiePat]

@dstorey: Using WebIDL to pull basic compatibility information is definitely an awesome idea and the MDN team is considering it (it's just a low priority currently as we have to move our curent data available from MDN first... but help is definitely welcome if you want to make usage of WebIDL faster, at minimum it worth opening an issue).

That said, it will never prevent manual work as it lack some key information such as which version of a given browser release an API publicly (sometimes months after the implementation started). Extracting that last information automatically from the code source can be quite tricky and always different from one browser to the other.

@chicoxyzzy: That's awesome! I suggest reaching out to @Elchi3 who is the current project lead for the MDN team.

[dstorey]

@JeremiePat I was hoping there would be some sort of tag or branch for releases. I know Safari has that at least and we'll likely have some method of getting that info if/when we (Edge) release our WebIDL (the more use cases like this the more justification we can get to do the work to open source them in some way) But yes, having manual overrides are useful for cases where the cases where it doesn't match reality

[Elchi3]

Awesome thread and thanks for considering collaboration! Feel free to ping me about further ideas!

MDN is generally interested in working more with the data coming from WebIDL files. For compat data purposes and documentation in general.

For browser-compat-data, we've focused on CSS properties, HTTP headers, HTML elements, and ECMAScript compat data so far, as these were the most interesting and also the ones lacking good compat data in other sources. And as said, they are often lacking any kind of (IDL) source to find out the truth. We've written a JSON schema and all compat data of the different web technologies are using the same compat data JSON schema in our repo (compat data is complex, so the schema is not yet 100% stable).

We've started to look into Web API data as well (while having WebIDL in mind), and decided to organize the compat data by interfaces, but the devil is in the details as we stumble upon things like mixins and non-object interfaces and the like. (see our discussion on mixins) If you have ideas on how to properly represent this, please jump in!

WebIDL and webplatform-tests are often mentioned to me to bring some kind of automation to the compat data sets. I think we will work on integrating these long-term, maybe not to (fully) auto-generate data, but at least to validate the data we're collecting. We will see :)

Last, I want to encourage you to make use of the data! MDN wiki pages are starting to build the compat tables from this new JSON data source, so our community of wiki editors is starting to maintain the compat data in the repo as opposed to the wiki pages. The more people are involved in consuming and caring about keeping the data up-to-date, the better for all compat data consumers, of course.

[chicoxyzzy]

As for ECMAScript, it's possible to use test262 suit for automatic data generation. There is discussion in compat-table repo.

Do you have JS engine version to web browser (or other environment) mapping data somewhere? We found that it's sometimes easier to generate browser JS compat data based on engine (this should be overridable though, sometimes environments differ even usinf same JS engine version). I think that rendering engine -> environment version mapping also may be useful.

[chicoxyzzy]

Also I found some relevant previous discussion in babel-preset-env repo https://github.com/babel/babel-preset-env/issues/354

[dstorey]

For edge it is actually possible to get the CSS info for declarations as we include all attributes in CSSStyleDeclaration (I noticed Chrome auto-generates these; i forget what Firefox does) and includes an enum with the values, e.g.:

    /// @css name="padding", animatable, shorthand, subproperties="padding-top padding-right padding-bottom padding-left", valuesyntax="1_to_4_space_separated_css_percentage_or_length", enumvalues="auto inherit initial unset"
    [CEReactions, TreatNullAs=EmptyString] attribute CSSOMString? padding;

HTML can be generated too. We include the reflect info (including name if different) for mapping IDL attributes to content attributes and we include the element the interface maps to as meta data at the top of the interface webidl, e.g.

/// @specs "html5"
/// @element name="a", ns="HTML", specs="html5"
/// @parsedattribute name="unselectable", valuesyntax="enum", enumvalues="off on"
[Exposed=Window, HTMLConstructor]
interface HTMLAnchorElement : HTMLElement
{
    [CEReactions, Reflect, ReflectValues=("_blank"|"_self"|"_parent"|"_top")]
    attribute DOMString target;
    ...

…of course we use non-standard IDL for a bunch of this, as all browsers do for their various enhancements. If we were to use this info it would be good to get browsers to use the same extended attributes and tags where possible. We've already been updating ours in places to match other browsers.

It is also possible to get the spec info as we include a @specs with the specref.org tag. We also have extended attributes for "Interop" (in more than one browser but not standard), "Deprecated" (was in a standard but no longer...in that case we put in a partial and include the last spec hash it was in for the @specs ref), and "Extension" (never been in a spec)

I'm not sure web plat test info is as useful as i first appears as it is very common (at least for edge) that a test fails for something completely unrelated to what it is testing (we failed 8k tests in execCommand for example until we added the DOM append/prepend methods for example). But it is one data point.

The mixin question is interesting. I'd lean towards doing what a parser would do and just include them in the interface they mixin to (which webidl would generate) as there are places where some browsers have the mixin and others only have the features on one interface for example as they haven't updated (languages would be an example of this in Edge where it has not been moved to work on workers yet). it could be stored in the back end json as a mixin like construct though. I guess there is some value in showing it belongs to a mixin to devs (probably more to browser devs than web devs) as it would highlight that the same feature is available on other interfaces, but maybe that could just be mentioned rather than be a separate mixin page.

[a2sheppy]

I guess there is some value in showing it belongs to a mixin to devs (probably more to browser devs than web devs) as it would highlight that the same feature is available on other interfaces, but maybe that could just be mentioned rather than be a separate mixin page.

The main advantage to documenting mixins separately is that this lets us avoid duplication of effort (and of content) by documenting these the mixins' methods and properties once instead of in every true interface in which they appear.

I do think we need to look at automatically embedding stuff inherited from mixins into the coverage of the interfaces that offer them, though. There are ways this can be done through automation. For instance, the experimental {{interface_overview}} macro, which is gradually being constructed to automatically generate the standard content of an interface overview page, could do things like automatically include all inherited items, both those from mixins as well as from parent interfaces.

This both reduces clicks to find what the user wants to get at, by listing everything in one page instead of doing the "Also inherits from..." links, but also of course improves content reliability by automating maintenance of these lists.

See the interface overview page for RTCPeerConnection, which currently uses {{InterfaceOverview}}, to see what this macro currently does. Right now, it doesn't automatically walk the inheritance chain or include mixins, but it could (and I think should) easily be updated to do so. The question would be whether to separate the inherited items out or just list them all in one list. I'm inclined to do the latter, but with some sort of an indicator added to show that the item is inherited.

Sheppy