Open foolip opened 5 months ago
The notion of links worth capturing may need to be clarified to avoid having to maintain the information in multiple places, especially as we're also considering collecting developer signals about features in a separate repository, including blogs, podcasts, or social media about a feature, which seem typical examples of things captured through links
in Can I Use.
That's a good point. Vendor signals as in https://github.com/web-platform-dx/web-features/pull/523 as definitely out of scope for the developer-signals repo, but beyond that things might get a bit tricky. Having "whatever links you like" in two places will no doubt create some interesting questions.
The reason I'm not inclined to just add a vendor_signals
or standards_positions
field is that I think it would be best maintained by those vendors themselves in their tooling. But I don't have any other kind of link I'd like to put in a links
field either.
Maybe "learn about it" links could make sense, and could link to resources like https://developer.chrome.com/blog/css-relative-color-syntax, but I'm not too excited about web-features being the arbiter of which resources are noteworthy and not.
The other way around: having other sources of information point to web-features by mean of our feature IDs, feels more scalable and maintainable. I hear WPT already uses tags that map to web-feature IDs. BCD entries do that too, for obvious baseline reasons. What if chromestatus.com did that as well? github.com/mozilla/standards-positions/ and github.com/WebKit/standards-positions/ could too.
What if chromestatus.com did that as well?
Yes, we're planning for that.
Caniuse has a
links
field which is used to populate a resources tab. Example: https://github.com/Fyrd/caniuse/blob/4910a6f82b0a5c1c3f181e5f35c0a0612b83288b/features-json/flexbox.json#L6-L76 https://caniuse.com/flexboxShould we have something similar in web-features, to allow adding any interesting links without structure?