Implicit default support values

[caugner]

What would you like to see added to BCD?

I'm proposing to introduce implicit default support values for certain browsers:

1. false (no support) for IE
2. "mirror" (same as upstream) for the following browsers:
   • chrome_android
   • firefox_android
   • oculus
   • opera
   • opera_android
   • safari_ios
   • samsunginternet_android
   • webview_android
   • webview_ios

Note

1. This is not a breaking change, because it only impacts the data stored in this repo, not the built and published BCD data.
2. This list intentionally excludes edge, which has significantly more non-mirrored statements (see below).
3. If we introduce statement-level annotations, we might still be able to set mirroring explicitly with a provenance:collector tag.

How impactful do you think this enhancement will be?

Overall, I believe that this change improves the authoring and reviewing experience.

As for IE, new web features are not supported for obvious reasons, so this entry just adds noise.

As for the mentioned downstream browsers:

• Implicit mirroring allows us to focus on the actual notable changes for these downstream browsers, so it reduces the chance of missing unintended "false" values during review, because these would then stand out, triggering the reviewer to look for corresponding evidence in the PR description.
• Currently, we seem to be adding "mirror" mostly without explicitly verifying this, because it is usually fair to assume that a feature supported in Chrome is also available in Chrome Android, and/or it isn't always straight-forward to verify.
• Recently, we've had some cases where false seems to have been set accidentally for some downstream browsers (ex 1, ex 2, ex 3, ex 4, ex 5).

Do you have anything more you want to share?

According to rg ': "mirror"' | wc -l, we have 132,276 instances of mirror in BCD.

As for mirroring, here are mirroring stats as of 2026-01-30 (total 16,831 features):

Browser	Count	Share
chrome_android	13564	81%
firefox_android	14572	87%
oculus	14938	89%
opera	12646	75%
opera_android	11285	67%
safari_ios	14246	85%
samsunginternet_android	14464	86%
webview_android	12130	72%
webview_ios	14734	88%
edge	9713	58%

(Source: for x in chrome_android edge firefox_android oculus opera_android safari_ios samsunginternet_android webview_android webview_ios; do printf "| $x | "; rg '"'$x'": "mirror"' | wc -l; done)

As for IE, false is currently set for 10,293 features (68%).

(Source: npm run stats --all --count on 4daafe2)

[ddbeck]

I'm 👎 toward any proposal that's going to make mirroring more opaque with new hidden behaviors.

This might make PRs easier to review, but makes exploring the committed data worse. For instance, under this proposal, finding out when some data changed for Chrome for Android becomes more difficult through Git blame, with little advantage over the current format. Likewise, using tools like grep and jq against the raw source becomes less usable (especially frustrating given the frequency of changes to main and the time nuisance to routinely build the head commit).

A more compelling alternative to this (at least to me) would be to make explicit what we're usually doing when we supply browser data. This isn't a full counterproposal (there are a bunch of details I have not confronted), but I'd much rather see "mirror" replaced with something like this as a common case, which reflects the underlying behavior of "mirror":

{
  "blink": {
    "version_added": "75"
  },
  "gecko": {
    "version_added": "48"
  },
  "ie": {
    "version_added": false
  },
  "webkit": {
    "version_added": "609.1.20"
  }
}

This could have the same effect as mirroring (that is, published data would continue to be per-browser), but with more transparency about the way we've collected the information. This would be in addition to, not a replacement for, explicit provenance notes.

Lastly, on this point specifically:

Currently, we seem to be adding "mirror" mostly without explicitly verifying this, because it is usually fair to assume that a feature supported in Chrome is also available in Chrome Android, and/or it isn't always straight-forward to verify.

This is a both a fault of mirroring and the current linter strategy. Right now, the linter enforces mirroring, clobbering data even if it has been verified. A "mirror" value can never mean that we know it's the same as the browser its mirroring from; it says that we assume it's the same.

[caugner]

Thanks for your input, Daniel. I’d like to clarify a few points.

1. This change isn’t about making mirroring more opaque. It’s about reducing noise in the raw data, thereby improving transparency in identifying meaningful downstream differences.
2. You mentioned that this proposal would make exploring the data more difficult, but a similar challenge exists today. If Chrome Android is set to "mirror", a git blame on Chrome Android alone is already insufficient. You must also check Chrome. My proposal makes this implicit, streamlining the authoring and review process without changing the actual data behavior.
3. Regarding grep and jq, while implicit mirrors would not appear in direct searches, if querying for "mirror" in the source files is a key use case, we should consider tooling improvements to support that. For example, we could generate a build where implicit mirrors are explicitly represented without resolving them.
4. Your concerns about the frequency of updates to main and the build time seem like separate issues. If this is an ongoing challenge, is there an existing issue tracking it? Addressing it independently might yield a more targeted solution.
5. Your alternative approach of explicitly listing engine-level data is interesting, but it assumes a direct correlation between engine support and browser support, which isn’t always the case, particularly for downstream browsers that diverge from their upstream sources. It seems that this would require mixing engines and browsers, which sounds like making authoring more complex and potentially more confusing.
6. Finally, the linter enforcing mirroring is a distinct discussion. The key issue is that mirroring, as it stands, is already an assumption rather than an assertion. Making it implicit aligns with reality while reducing unnecessary redundancy in the source files.

I still believe this proposal enhances both authoring and reviewing without compromising transparency. Looking forward to your thoughts.

PS: We could start with IE, making false it's implicit default, and see how that goes.

[ddbeck]

Florian and I chatted a bit about this at the BCD call yesterday. And I've had some time to think about this more. I'll respond to your specific points below, but a more fruitful route here might be to do something like this:

File an issue describing the problem that's most troubling for which this issue is intended to fix. If the main problem is "missing unintended "false" values during review" (or whatever), then let's have a discussion about the frequency and impact of that problem and all the range of possible solutions.

Mostly, I'm just not sure whether this is the most well-targeted solution to the problem, because I'm not that clear on what the problem is.

---

2. You mentioned that this proposal would make exploring the data more difficult, but a similar challenge exists today. If Chrome Android is set to "mirror", a git blame on Chrome Android alone is already insufficient. You must also check Chrome. My proposal makes this implicit, streamlining the authoring and review process without changing the actual data behavior.

I don't think I made myself clear. This proposal makes it harder to find changes to the fact of mirroring itself, not the results of mirroring.

For instance, if a Chrome for Android value changes from a specific version to mirror (e.g., { "version_added": "100" } to "mirror"), it's possible to find that change via successive blames starting with the JSON at main's head commit. In the current mirroring behavior, there are always lines in the file associated with Chrome for Android on which to blame. (I use the GitHub blame UI for this kind of investigation on a regular basis.)

Under this proposal, it would be harder to discover and follow that change because there would be no set of lines in the file that would necessarily relate to Chrome for Android. To find that change, I would have to first find the last time a "chrome_android" line existed in the file before tracing the changes backwards—and there would be no guarantee that line ever existed. I certainly wouldn't discover it by casually blaming the JSON at HEAD.

3. Regarding grep and jq, while implicit mirrors would not appear in direct searches, if querying for "mirror" in the source files is a key use case, we should consider tooling improvements to support that. For example, we could generate a build where implicit mirrors are explicitly represented without resolving them.

Maybe? I'd have to watch more carefully about how I'm using these things in practice. I think I often use grep and jq to find things to blame—I'd probably just stop using them, honestly.

4. Your concerns about the frequency of updates to main and the build time seem like separate issues. If this is an ongoing challenge, is there an existing issue tracking it? Addressing it independently might yield a more targeted solution.

I can file an issue about it, but I haven't filed one. In BCD calls, I've twice brought up the possibility of a readily-available builds from CI. Both times, I got negative feedback on the idea. 🤷

5. Your alternative approach of explicitly listing engine-level data is interesting, but it assumes a direct correlation between engine support and browser support, which isn’t always the case, particularly for downstream browsers that diverge from their upstream sources. It seems that this would require mixing engines and browsers, which sounds like making authoring more complex and potentially more confusing.

Yeah, we could develop this idea more completely. I don't think it would be an "everything" solution—just a utility for the common case, where all "mirror" values are in exercise for all browsers of that engine (i.e., blink would have to be mutually exclusive with any of chrome, chrome_android, edge, etc.).

6. Finally, the linter enforcing mirroring is a distinct discussion. The key issue is that mirroring, as it stands, is already an assumption rather than an assertion. Making it implicit aligns with reality while reducing unnecessary redundancy in the source files.

I don't think it's a separate discussion. You raised the issue that "we seem to be adding "mirror" mostly without explicitly verifying" — but the current linter configuration says that a contributor may never explicitly show that data was independently confirmed for that browser, if the version numbers coincide. This can only be done out of context, in PRs or issues.

PS: We could start with IE, making false it's implicit default, and see how that goes.

There's been a long-deferred discussion item on the BCD meeting agenda notes about dropping IE. I think there are some very specific data quality issues for Edge that could be resolved that would open the door to dropping IE altogether. Before doing anything special for IE, I think we should have at least one IE-dropping discussion, to gauge whether doing anything for IE is worth anyone's time.

[caugner]

To use this example from #25735:

Here's how the JSON currently looks:

{
  "__compat": {
    "description": "Cross-origin",
    "mdn_url": "https://developer.mozilla.org/docs/Web/API/LargestContentfulPaint/renderTime#cross-origin_image_render_time",
    "tags": [
      "web-features:largest-contentful-paint"
    ],
    "support": {
      "chrome": {
        "version_added": "133"
      },
      "chrome_android": "mirror",
      "edge": "mirror",
      "firefox": {
        "version_added": false
      },
      "firefox_android": "mirror",
      "ie": {
        "version_added": false
      },
      "oculus": "mirror",
      "opera": "mirror",
      "opera_android": "mirror",
      "safari": {
        "version_added": false
      },
      "safari_ios": "mirror",
      "samsunginternet_android": "mirror",
      "webview_android": "mirror",
      "webview_ios": "mirror"
    },
    "status": {
      "experimental": false,
      "standard_track": true,
      "deprecated": false
    }
  }

And here's how it would look (much cleaner) with implicit default support values:

{
  "__compat": {
    "description": "Cross-origin",
    "mdn_url": "https://developer.mozilla.org/docs/Web/API/LargestContentfulPaint/renderTime#cross-origin_image_render_time",
    "tags": [
      "web-features:largest-contentful-paint"
    ],
    "support": {
      "chrome": {
        "version_added": "133"
      },
      "edge": "mirror",
      "firefox": {
        "version_added": false
      },
      "safari": {
        "version_added": false
      },
    },
    "status": {
      "experimental": false,
      "standard_track": true,
      "deprecated": false
    }
  }
}