Caniuse and MDN compatibility data collaboration | Hacker News Reader

Caniuse and MDN compatibility data collaboration

hacks.mozilla.org

240 pointsweinzierl10 comments

I tried to submit some data but the MDN format seemed to me to be poorly thought out to me (though maybe I just didn't get it).

If I understood correctly, in order to add any data you need to add data for all browsers. You can't just say "Browsers X,Y,Z support API Foo but Z does't support option B". Instead you have to say "Of all supported browsers A,B,C,D,E,F,G,H,I do not support foo and X,Y,Z do support foo. For option B A,B,C,D,E,F,G,H,I,X,Y don't know if they support option B. Z does not support option B"

What I was trying to document is bugs but I only know 1 or 2 browsers detail not the other 9 or 12, or how ever many it's up to. I don't really want have to put "I don't know" for a bunch of other browsers.

Further, when a broswer says it supports say "AudioContext" but because of a bug feature X doesn't work in say Safari, I really just want to document that all browsers that claim to support "AudioContext" support all features except Safari was has one exception. I don't want to have to say Edge, Chrome, Firefox, Opera, Opera Mini, Android Mobile, "don't know" because by default, if they claim they support "AudioContext" then they should be supporting feature X. So you run into this combinitorial issue that you need people go dig through and prove that each of those other browsers support feature X or you need to mark "unknown", neither of which really represents what you're trying to document.

It seemed quite straightforward to me last time I wanted to update something: there is boilerplate (schema [0]) JSON for feature / subfeature that lists all browsers in current documentation set with `{"version_added": null}` meaning "I don't know if given browser supports this feature" [1]. It's probably fine to introduce feature with completely unknown support just to ease future updates. I'm not sure if introduced feature should be in some advanced standardization process stage or not.

For bugs and details in implementations you can use `{versoin_added: true, notes: ["not in conditions described in <a href='...'>some bugreport</a>"]}` [2].

[0] https://github.com/mdn/browser-compat-data/blob/4f34583ab491... [1] https://github.com/mdn/browser-compat-data/blob/master/schem... [2] https://github.com/mdn/browser-compat-data/blob/master/schem...

In order to help ensure that data gets filled out and we don't wind up with strays, we stopped allowing the null value for a version, so you can no longer indicate "unknown" as support level for a feature in BCD's data store. If you don't know the values, you can submit a patch but someone will have to add the missing data before it can be accepted, as it will fail the automated testing without data for every browser supported by the JSON.

that seems in scalable and adds such a burden to adding data that it will have the unintended consequence of discouraging participation.

I only have a dataset of 1 but it seems like it would be useful data for devs to see so they know they can not use features X, Y, and Z if they want to be cross platform because of bugs in specific implementation but given I can't add the data without going through all the browsers, given that "unknown" is not the right label for conforming browsers, and given that I don't have time to dig up proof the other browsers conform I opted to remove my pull request

That's sad. While understandable if you were overwhelmed with poor half-hearted "stray" PRs, still I doubt that any random developer will sift trough open PRs to add his two cents of knowledge about "invisible" (unpublished) feature to make it complete for acceptation. Seeing blanks-to-be-filled directly in public documentation feels far more motivating for quick ("wiki") edit.

Before caniuse, I remember my goto site was quirksmode[0]. Not only did it had the compatibility tables but also great advice and pages with test for everything.

[0] https://www.quirksmode.org/compatibility.html

We should probably amalgamate this with the one we have at https://kangax.github.io/compat-table/

Agreed, yours and the https://node.green/ subset are tools I use often.

Wow, "UC Browser for Android" has 3.5% market share and does not support javascript modules.

Well, UC Browser for Android has ~17% market share in India.

Reply on news.ycombinator.com