You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the context of #2004 we discussed the benefits of grouping features together vs having separate features.
Now that I'm looking at the State of JS 2024, I have another example of this issue in the form of set methods.
I just wanted to point out that one reason in favor of splitting these into separate features (at least for my use case) would be for clients to be able to access things like feature-specific code examples or MDN URLs via the API.
If we did split up the set methods into individual features, maybe the current "Set methods" could instead be a feature group?
The text was updated successfully, but these errors were encountered:
We discussed this today on the WebDX call (minutes).
A couple of highlights from our discussion:
MDN has a similar use case whereby they have reference pages that discuss sub-parts of our features, and they still display the baseline badges on these pages. The way they do this is by using the compute-baseline package which gives them the status of a single BCD key as part of a web-feature.
This might be something you could use here.
About documentation links
This is something that's very interesting to us as well. Right now, the only thing you can do is list the BCD keys for a feature, and derive the list of MDN URLs from it. But, that's not great because certain features have dozens of BCD keys.
On the web-features-explorer website, I started mapping web-features to MDN URLs in a way where, for each feature, there's one or at most a small number of MDN URLs. For example, now instead of having the list of all MDN articles about each and every feature of grid, for the grid web-feature, we have just one link to the CSS Grid layout article. The mapping is maintained here: https://github.com/web-platform-dx/web-features-explorer/blob/main/mdnDocsOverrides.json
We also discussed about the fact that it would be very helpful if the MDN project would help maintain this mapping instead. It could flag certain articles with the web-features IDs they relate to. @pepelsbey said he would bring this up with the MDN team next week
About sample code
We felt like this was a bit out of scope for the web-features project. Perhaps if there was a well-maintained, authoritative, repository for web feature code snippets, then we could map to that. Just like we try to map to BCD, caniuse, StateOf, chromestatus, WPT, etc. by having hese external resources point to us, using the feature IDs.
Now this doesn't completely answer your question about the set methods feature. Indeed, if we did split up this feature, and if we had that MDN URL mapping I talked about, then you'd at least get links to MDN covered.
In the context of #2004 we discussed the benefits of grouping features together vs having separate features.
Now that I'm looking at the State of JS 2024, I have another example of this issue in the form of set methods.
I just wanted to point out that one reason in favor of splitting these into separate features (at least for my use case) would be for clients to be able to access things like feature-specific code examples or MDN URLs via the API.
If we did split up the set methods into individual features, maybe the current "Set methods" could instead be a feature group?
The text was updated successfully, but these errors were encountered: