Ancestors affecting a key's computed status is difficult to understand

[ddbeck]

Summary

compute-baseline checks a compat key's ancestors when resolving a key's status (that is, support for x.y.z is based on the intersection of x.y.z., z.y, and x). This is expected, but surprising, behavior. When this happens, it's quite difficult to see this result and understand why.

Example

For example, given the key api.Bluetooth.requestDevice, we get this status:

baseline: false
support:
  chrome_android: 56

But actual support shown for that key on the MDN compat table (and the BCD for that key alone) looks quite different (from Bluetooth: requestDevice() method - Web APIs | MDN):

The cause of this is the parent Bluetooth interface (from Bluetooth - Web APIs | MDN), which is only partially supported:

Related issues and PRs

This originally came up in https://github.com/web-platform-dx/web-features/pull/1376/files#r1675836543, where Linux support prevented the feature from having a higher level of support. It was suggested that we might want the option to override that, file as #1690.

This issue is about how it's hard to tell that it has happened at all.

[ddbeck]

Some ideas on how to approach this problem:

• Print BCD notes into dist files
• Annotate keys in dist files that have a different status because of an ancestor (and, ideally, which one)

[ddbeck]

cc: @fiji-flo, @LeoMcA I tracked down the cause of the troublesome key. See https://github.com/web-platform-dx/web-features/pull/1376/files#r1675836543 for a bit of background. The very short summary: this is expected, but we could make it easier to understand why it has happened.