Open foolip opened 2 months ago
I was surprised that see the support
object being empty too. Would it make sense to still populate that object even if baseline is false?
I think it'd be good to populate it with all of the core browser set, and setting the value to false where not supported. Is that what you mean?
Yeah, I think that would be ideal. This way, consumers have a consistent list of browsers in each feature's support
object, whether a feature is supported in 0 or N browsers, and whatever its baseline status (false, low, high):
For example:
"audio-session": {
"compat_features": [ ... ],
"description": "...",
"description_html": "...",
"name": "Audio session",
"spec": "https://w3c.github.io/audio-session/",
"status": {
"baseline": false,
"support": {
"chrome": false,
"chrome_android": false,
"edge": false,
"firefox": false,
"firefox_android": false,
"safari": "16.4",
"safari_ios": "16.4"
}
}
}
"anchor-positioning": {
"compat_features": [ ... ],
"caniuse": "css-anchor-positioning",
"description": "...",
"description_html": "...",
"name": "Anchor positioning",
"spec": "https://drafts.csswg.org/css-anchor-position-1/#anchoring",
"status": {
"baseline": false,
"support": {
"chrome": "125",
"chrome_android": "125",
"edge": "125",
"firefox": false,
"firefox_android": false,
"safari": false,
"safari_ios": false
}
}
}
For comparison, anchor-positioning is currently:
"anchor-positioning": {
"compat_features": [ ... ],
"caniuse": "css-anchor-positioning",
"description": "...",
"description_html": "...",
"name": "Anchor positioning",
"spec": "https://drafts.csswg.org/css-anchor-position-1/#anchoring",
"status": {
"baseline": false,
"support": {}
}
}
OK, I think what needs to happen here is:
support
Map
shows all the browsers (even pre-releases) but toJSON()
's support
shows only shipped browsers as a version numbertoJSON()
's support
object shows explicit false values for things that we know are not supporteddist.ts
to insert comments alongside unsupporting browsers saying that they're preview/future (i.e., add a comment when support is different from toJSON()
support
)Change computeBaseline such that the returned
support
Map
shows all the browsers (even pre-releases) buttoJSON()
'ssupport
shows only shipped browsers as a version number
That reduction seems best to make more explicit than toJSON()
, perhaps toBaselineSupport()
.
In https://github.com/web-platform-dx/web-features/pull/952 I was surprised that Chrome 125 wasn't listed, but it's because that's in beta.
@ddbeck can we put something in dist files that provides a clue that something is in beta, so that we can be confident we got the list of BCD keys correct before it hits stable?