Update Chromium versions for BluetoothRemoteGATTService API by queengooborg · Pull Request #10197 · mdn/browser-compat-data

queengooborg · 2021-05-02T12:01:18Z

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

This PR updates and corrects the real values for Microsoft Edge for the `BluetoothRemoteGATTService` API, based upon results from the [mdn-bcd-collector](https://mdn-bcd-collector.appspot.com) project (v3.0.1). Results are manually confirmed for accuracy. Tests Used: https://mdn-bcd-collector.appspot.com/tests/api/BluetoothRemoteGATTService

api/BluetoothRemoteGATTService.json

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 · 2021-05-19T08:17:19Z

api/BluetoothRemoteGATTService.json

            "ie": {
              "version_added": false
            },
-            "opera": [


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?

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.

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

ddbeck · 2021-05-19T13:55:42Z

api/BluetoothRemoteGATTService.json

            "ie": {
              "version_added": false
            },
-            "opera": [


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.

api/BluetoothRemoteGATTService.json

foolip · 2021-05-24T07:54:38Z

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.

This is a subset of mdn#10197.

ddbeck · 2021-05-25T14:15:44Z

@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 · 2021-05-28T15:08:19Z

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 · 2021-06-04T11:10:41Z

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 · 2021-06-08T10:09:20Z

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 · 2021-06-09T12:13:58Z

This commit should do the trick?

stale

queengooborg · 2021-07-14T17:06:03Z

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

api/BluetoothRemoteGATTService.json

foolip · 2021-07-14T21:26:02Z

api/BluetoothRemoteGATTService.json

            "ie": {
              "version_added": false
            },
-            "opera": [


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

foolip · 2021-07-14T21:40:36Z

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

github-actions bot added the data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API label May 2, 2021

foolip reviewed May 5, 2021

View reviewed changes

api/BluetoothRemoteGATTService.json Show resolved Hide resolved

queengooborg changed the title ~~Update Edge versions for BluetoothRemoteGATTService API~~ Update Chromium versions for BluetoothRemoteGATTService API May 14, 2021

queengooborg added 3 commits May 14, 2021 07:12

Fix Chrome data

663e389

Simplify data for subfeatures

3335289

Cleanup Edge data a little bit

ae97cb3

foolip approved these changes May 19, 2021

View reviewed changes

ddbeck previously requested changes May 19, 2021

View reviewed changes

queengooborg added 2 commits May 21, 2021 06:43

Simplify OS-varying data

38e5f01

Merge branch 'main' into api/BluetoothRemoteGATTService/edge-corrections

ab0a6b5

foolip mentioned this pull request May 24, 2021

Remove api/s that has never been supported #10581

Merged

saschanaz added a commit to saschanaz/browser-compat-data that referenced this pull request May 24, 2021

Update BluetoothRemoteGATTService members where no support data exists

d3e9c06

This is a subset of mdn#10197.

saschanaz mentioned this pull request May 24, 2021

Update BluetoothRemoteGATTService members where no support data exists #10620

Closed

Edimalius approved these changes May 31, 2021

View reviewed changes

Add partial implementation

cffac2e

ddbeck requested a review from foolip June 10, 2021 16:36

foolip approved these changes Jul 14, 2021

View reviewed changes

Update api/BluetoothRemoteGATTService.json

5529bb6

foolip merged commit 2a6487a into mdn:main Jul 14, 2021

queengooborg deleted the api/BluetoothRemoteGATTService/edge-corrections branch July 14, 2021 21:36

foolip mentioned this pull request Jul 14, 2021

Make Bluetooth API OS support notes consistent across files #11532

Closed

8 tasks

This was referenced Jul 23, 2021

Correct Chromium data for Bluetooth APIs and make consistent #11715

Merged

api.BluetoothRemoteGATTService.getCharacteristics/isPrimary - Supported on Chrome #9210

Closed

Conversation

queengooborg commented May 2, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

foolip left a comment

Choose a reason for hiding this comment

Uh oh!

foolip May 19, 2021

Choose a reason for hiding this comment

Uh oh!

ddbeck May 19, 2021

Choose a reason for hiding this comment

Uh oh!

foolip Jul 14, 2021

Choose a reason for hiding this comment

Uh oh!

ddbeck May 19, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

foolip commented May 24, 2021

Uh oh!

ddbeck commented May 25, 2021

Uh oh!

foolip commented May 28, 2021

Uh oh!

Edimalius left a comment • edited by queengooborg Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ddbeck commented Jun 4, 2021

Uh oh!

foolip commented Jun 8, 2021

Uh oh!

queengooborg commented Jun 9, 2021

Uh oh!

queengooborg commented Jul 14, 2021

Uh oh!

Uh oh!

foolip Jul 14, 2021

Choose a reason for hiding this comment

Uh oh!

foolip commented Jul 14, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

queengooborg commented May 2, 2021 •

edited

Loading

Edimalius left a comment •

edited by queengooborg

Loading