Link web-features data to browser standards-positions

[ddbeck]

I think the best way to capture that would be a standards_positions field that can link to issues in https://github.com/mozilla/standards-positions or https://github.com/WebKit/standards-positions.

Originally posted by @foolip in #183 (comment)

[captainbrosset]

I think there are discussions to do this in BCD too. Also worth noting that Chrome and Edge don't have a standards positions repo.

[foolip]

Alternatively we ask the maintainers of those repos to use some tagging mechanism so they can maintain the mapping. For chromestatus that's what I'd like to do at least.

[captainbrosset]

I do think we need something here. For both BCD and web-features. It's different to say "this feature is not yet implemented in browser X", than to say "this feature is not implemented in browser X, see browser X's position about it at ...".

Currently, neither BCD and web-features tell this story, and I think it would be useful for web developers to know. They might be contemplating using an API, without knowing that it will simply never be implemented in some browser (that is, unless the feature's design changes substantially).

---

Example: Idle Detection

Baseline badge and BCD table

They both simply say that the feature is not supported:

Standards positions

They tell a different story

• Mozilla: https://mozilla.github.io/standards-positions/#idle-detection-api

  We are concerned about the user-surveillance, user-manipulation, and abuse of user resources potential of this API ...

• WebKit: https://lists.webkit.org/pipermail/webkit-dev/2020-October/031565.html

  Unless a significant new development is being made in either one of the issues we've raised, our position will remain to object to the addition of this API unless otherwise stated regardless of whether we continue to say so in public or not.

---

Deciding if the data should be maintained in those positions repos (by using tags that match our web-features' IDs), or in the present repo or in BCD (by using boolean statuses and links) seems like an implementation choice we can always change later.

@Elchi3 I seem to remember BCD wanting to collect this information. Did this happen?

I'd also value @jgraham's and @annevk's points of view on this issue. Would you be open to adding a field in your positions JSON data that maps back to the web-features maintained here?
For Idle Detection, for Mozilla for example, this could like this:

  {
    "ciuName": null,
    "description": "This document defines a web platform API for observing system-wide user presence signals.",
    "id": "idle-detection-api",
    "mozBugUrl": "",
    "mozPosition": "negative",
    "mozPositionDetail": "We are concerned about the user-surveillance, user-manipulation, and abuse of user resources potential of this API, despite the required 60 second mitigation. Additionally it seems to be an unnecessarily powerful approach for the motivating use-cases, which themselves are not even clear they are worth solving, as pointed out in <a href=\"https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html\">https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html</a>",
    "mozPositionIssue": 453,
    "org": "Proposal",
    "title": "Idle Detection API",
    "url": "https://wicg.github.io/idle-detection/",
    "web-features-tag": "idle-detection"
  },

[hober]

@captainbrosset wrote:

For both BCD and web-features. It's different to say "this feature is not yet implemented in browser X", than to say "this feature is not implemented in browser X because they oppose this feature of the web platform, learn more at ...".

"because they oppose this feature of the web platform" is poor framing that presumes a disputed outcome—if a feature is only implemented in one engine, it's by definition not part of the web platform.

[ddbeck]

I think this continues to be a nice-to-have (it'd be helpful for confirming the results of computed statuses, for instance), but I don't think we should put any effort into a schema until there's a consumer that's actually going to attempt to tell a story to web developers with such data.

Last I heard, there was not enthusiasm on MDN or caniuse's part to make this information prominent. Until we hear from someone saying that they're going to do something with this data, I'd prefer to see what Philip suggested in #186 (comment).

[captainbrosset]

@hober wrote:

"because they oppose this feature of the web platform" is poor framing that presumes a disputed outcome—if a feature is only implemented in one engine, it's by definition not part of the web platform.

Thanks for the feedback, I agree about removing the "web platform" part of it and I've updated my comment to say "this feature is not implemented in browser X, see browser X's position about it at ..." instead.

[captainbrosset]

@ddbeck I agree with not doing anything until consumers of the data share a need for this with us. And I also prefer Philip's suggestion, which is why I'd like to hear what folks who maintain browser position repos think about adding web-features IDs to their data.

[annevk]

FWIW, I think we'd probably accept patches, but I'm not sure about actively investing in the accuracy of that data.

[jgraham]

I think there are use cases for this which don't depend on user-facing consumers.

For example for Interop if a proposal corresponds to a web-feature (which hopefully is the most common case, particularly if we support features being defined before implementations ship) we could automatically pull in the s-p data from different vendors so it wouldn't require additional manual effort to find vendor's existing positions on the feature.

[atopal]

@annevk you mean you'd accept patches for the https://github.com/WebKit/standards-positions repo? If we follow Philip's proposal, once we tag those positions with the Web Feature identifiers, you'd only need to keep the repo itself up to date.

[captainbrosset]

I just proposed this PR for Mozilla: mozilla/standards-positions#1034
I plan on opening a similar one for WebKit.