Make it obvious when something is in beta/preview/nightly

[foolip]

In #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?

[captainbrosset]

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?

[foolip]

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?

[captainbrosset]

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:

  "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:

  "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": {}
    }
  }

[ddbeck]

OK, I think what needs to happen here is:

• Change computeBaseline such that the returned support Map shows all the browsers (even pre-releases) but toJSON()'s support shows only shipped browsers as a version number
• Change computeBaseline such that the toJSON()'s support object shows explicit false values for things that we know are not supported
• Change dist.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)

[foolip]

Change computeBaseline such that the returned support Map shows all the browsers (even pre-releases) but toJSON()'s support shows only shipped browsers as a version number

That reduction seems best to make more explicit than toJSON(), perhaps toBaselineSupport().