Compatibility Data Proposal

MDN
#1

I’ve been meaning for quite a while to document how I look up what version of Chrome something is supported in. The tools I use are open to the public. Many PRs in browser-compat-data have a discussion about Chrome support that ends with some version of 'cc-ing Joe." People other than me should know how to look things up.

I wasn’t really sure where those instructions should live. What if we created a place in bcd, where any browser vendor could put such instructions? I suspect this would end up being multiple markdown files, so it probably needs its own folder, but I have no strong preferences on exactly how we do it.

Thoughts?

2 Likes
#2

This is a great idea Joe. It would be great to do the same for Firefox and other browsers too, either in the same doc or separate ones.

I’ve got BCD docs on MDN too: https://developer.mozilla.org/en-US/docs/MDN/Contribute/Structures/Compatibility_tables

We also tend to document MDN internal stuff how-to guides at https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto

So there is a bit of a choice of where to put such information. It depends on if we feel it should be on MDN or closer to the project itself. What do we think?

1 Like
#3

The information I’m proposing should probably live pretty close /Structures/Compatibility_tables with something in the bcd README.md or CONTRIBUTING.md pointing to them. Again, I’m not real particular about where it goes, but since you’re open to publishing it, I’ll raise its priority on my list of things to do.

#4

I’d suggest having a page located under Structures/Compatibility_tables
(maybe Structures/Compatibility_tables/Finding_data or something like that)
which would list out information for each browser about where to go to get
details, how to ferret out the version in which a feature shipped, etc.
Then link to that page from the main compat tables page as well as from
CONTRIBUTING.md.

#5

Since the long term vision for BCD is for them to appear in all sorts of places, not just MDN, it might be good to have the docs about maintaining them located closer to the data. But in the immediate term, the locations mentioned on MDN seem fine to me.

1 Like
#6

I agree with Janet, the documentation about this could have a good place inside the bcd repository.

And on a technical level, I believe we can configure npm to avoid publishing this documentation inside the package making this a blank operation on the package in itself.

#7

I don’t have a strong opinion here WRT to placement (the repo itself versus MDN, which is closely affiliated with the repo anyway).

I think in terms of findability, it might be better to have it located in the repo itself. Let’s have it placed in an MD file called “finding-data.md” or similar, which Joe can add the Chrome information to, and I can then add information to on finding Fx data.

1 Like
#8

Another option is the GitHub wiki:

I find this works well for rapidly changing information that can be updated by the community. The README could point to a page on the wiki.