Caniuse and MDN compatibility data collaboration


240 points | by weinzierl 136 days ago


  • greggman2 136 days ago

    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.

    • myfonj 135 days ago

      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] [1] [2]

      • a2sheppy 134 days ago

        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.

        • greggman2 134 days ago

          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

          • myfonj 133 days ago

            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.

      • hiccuphippo 135 days ago

        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.


        • kangax 135 days ago

          We should probably amalgamate this with the one we have at

        • FreeHugs 136 days ago

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

          • geekybiz 135 days ago

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