Update Chromium versions for BluetoothRemoteGATTService API

[queengooborg]

This PR updates and corrects the real values for Chrome-based browsers for the BluetoothRemoteGATTService API, based upon results from the mdn-bcd-collector project (v3.0.1). Additionally, this simplifies the child data for the API, removing the redundant multiple statements and derived flag data. Results are manually confirmed for accuracy.

Tests Used: https://mdn-bcd-collector.appspot.com/tests/api/BluetoothRemoteGATTService

[foolip]

Looks good, but I'd also like @ddbeck to take a look at the question of deduplicating.

Note that searching for "macOS only" finds a bunch more cases like this, and probably it's best to delete all of that in a single PR, separate from fixing the data?

[foolip]

I agree with simplifying all of this repeated OS and flag information since it's already on the parent feature. But it does mean that information won't be visible on a page like https://developer.mozilla.org/en-US/docs/Web/API/BluetoothRemoteGATTService/getCharacteristic#browser_compatibility.

@ddbeck how do you think we should deal with cases like this?

[ddbeck]

There's some disagreement on this point. See #6509 for the broader issue.

My approach to flags has been to only represent the flag on the feature that requires the flag, not its descendants (unless the flags differ). For example, a CSS property behind a flag doesn't need to duplicate the flag data on subfeatures for property values. This does lead to a poorer presentation for individual interface member pages, however. In those cases I don't think it's too bad: for SomeFlaggedInterface.method(), you'd get an informative SomeFlaggedInterface is not defined error.

But since there's no consensus, I'm happy to allow anything that looks reasonable. If you think it'd be preferable to have flags inherit, then go for it, but I'm not going to ask for it myself.

[foolip]

I'll go along with removing the flags on subfeatures here. I don't know what I think should be the guideline :)

[ddbeck]

There's some disagreement on this point. See #6509 for the broader issue.

My approach to flags has been to only represent the flag on the feature that requires the flag, not its descendants (unless the flags differ). For example, a CSS property behind a flag doesn't need to duplicate the flag data on subfeatures for property values. This does lead to a poorer presentation for individual interface member pages, however. In those cases I don't think it's too bad: for SomeFlaggedInterface.method(), you'd get an informative SomeFlaggedInterface is not defined error.

But since there's no consensus, I'm happy to allow anything that looks reasonable. If you think it'd be preferable to have flags inherit, then go for it, but I'm not going to ask for it myself.

[foolip]

The "macOS only.", "Linux and versions of Windows earlier than 10.", and "Windows 10." notes are very widespread, although inconsistently applied, and it would be great to change them all at once to not create confusion for future contributors trying to update parts of this data.

Some of the data also indicates unconditional support, like api.BluetoothRemoteGATTCharacteristic.writeValueWithResponse. It would be good to decide what level of OS support we should consider complete and consistently either drop notes or add them where missing.

[ddbeck]

@foolip Yeah, I understand this stuff is widespread. We did adopt a guideline to try to encourage new data to be more consistent when it comes to OS limitations: https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#operating-system-limitations-imply-partial_implementation. We could revise it to be more assertive about what note is needed (e.g., "You must have a note that reads, …").

[foolip]

Right, so it should be partial_implementation in a lot of cases here, but when does it stop being partial_implementation? Chrome is supported on Windows, macOS, Linux and ChromeOS. The simple answer would be to say that it's partial_implementation if something isn't supported on any of those platforms. What feels a bit weird about that is that Linux support in particular won't matter much to web developers, since it's not a very significant part of the user share.

[Edimalius]

[Spam]

[ddbeck]

The simple answer would be to say that it's partial_implementation if something isn't supported on any of those platforms. What feels a bit weird about that is that Linux support in particular won't matter much to web developers, since it's not a very significant part of the user share.

My glib answer to that is: well, if a browser claims to support Linux, then excluding some features from Linux seems like a partial implementation to me.

But I get where you're coming from. I'd accept a revision of the guidelines to say something like, if it's not supported on either of the top two desktop operating systems (citing some source which names Windows and macOS), then the partial_implementation flag is required; otherwise, only the note is required.

[foolip]

My glib answer to that is: well, if a browser claims to support Linux, then excluding some features from Linux seems like a partial implementation to me.

Let's go with that simpler solution for now. @vinyldarkscratch do you feel like wrangling the Bluetooth into that shape? Alternatively, updating data in a way that matches the current structure and filing an issue about the Bluetooth data would be OK with me.

[queengooborg]

This commit should do the trick?

stale

[queengooborg]

Hey @foolip, could you give this one a re-review when you are able?

[foolip]

I'll go along with removing the flags on subfeatures here. I don't know what I think should be the guideline :)

[foolip]

I've filed #11532 about making the remaining data consistent with this.