Add WebHID feature #183
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| spec: https://wicg.github.io/webhid/ | ||
| caniuse: webhid | ||
| usage_stats: https://chromestatus.com/metrics/feature/timeline/popularity/2865 | ||
| status: | ||
| is_baseline: false | ||
| support: | ||
| chrome: "89" | ||
| edge: "89" | ||
| compat_features: | ||
| - api.HID | ||
| - api.HID.connect_event | ||
| - api.HID.disconnect_event | ||
| - api.HID.getDevices | ||
| - api.HID.requestDevice | ||
| - api.HIDConnectionEvent | ||
| - api.HIDConnectionEvent.HIDConnectionEvent | ||
| - api.HIDConnectionEvent.device | ||
| - api.HIDDevice | ||
| - api.HIDDevice.close | ||
| - api.HIDDevice.collections | ||
| # - api.HIDDevice.forget | ||
|
There was a problem hiding this comment. I'm guessing you omitted this one because it landed several versions later. What do you think of including it anyway, and advancing the Chrome and Edge version numbers? This would make the group more complete to the contemporary API without strongly altering the compatibility story. There was a problem hiding this comment. It's a good question. Should we be more liberal about updating groups for features that are "new"? I'm inclined to say no actually, and think we should handle this situation the same as we would given a new feature that ships in all browsers around the same time, and then gets some small later. I think the feature as a whole should still use the older launch date. What do about api.HIDDevice.forget then? I don't know. We have this question sprinkled all over our YAML files now. There was a problem hiding this comment.
OK, that's a fair point. I think the overriding thing ought to be developer expectations: if we get information that And I'd be probably be less reluctant to split things, if we had already worked out group composition (e.g., "WebHID (kitchen sink)" = "WebHID" + "forget"). So let's keep this as is, then sort out composition so we don't have to have these conversations as often. 😄 There was a problem hiding this comment. I agree that developer expectations trumps all. |
||
| - api.HIDDevice.inputreport_event | ||
| - api.HIDDevice.open | ||
| - api.HIDDevice.opened | ||
| - api.HIDDevice.productId | ||
| - api.HIDDevice.productName | ||
| - api.HIDDevice.receiveFeatureReport | ||
| - api.HIDDevice.sendFeatureReport | ||
| - api.HIDDevice.sendReport | ||
| - api.HIDDevice.vendorId | ||
| - api.HIDInputReportEvent | ||
| - api.HIDInputReportEvent.data | ||
| - api.HIDInputReportEvent.device | ||
| - api.HIDInputReportEvent.reportId | ||
| - api.Navigator.hid | ||
| - http.headers.Permissions-Policy.hid | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice to have a TODO comment or an issue noting that this is a… conflicted specification. That is, Apple and Mozilla are explicitly not prototyping/implementing the spec. That's an interesting bucket that I imagine we'll get to eventually and it'd be nice to have a way to come back to it when we're ready to add it to the schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the best way to capture that would be a
standards_positionsfield that can link to issues in https://github.com/mozilla/standards-positions or https://github.com/WebKit/standards-positions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tracked in #186