Add earlier dates as comments in dist YAML

[foolip]

Spinning off this idea from #837.

When trying to make a group from many BCD keys, my process is:

• Add just the entry points for the API, usually one or a handful of keys.
• See what browser versions and Baseline low date result from that
• Add as many keys as possible without changing any versions or dates

The last step is hard, and I've bisected large lists to figure it out. Boo.

@ddbeck has Markdown tables that could be reinstated.

A complementary approach is to add dates to the individual keys in the generated dist wherever it doesn't match the Baseline low date (after override, if any).

This way, any key with a comment after it is one that changes something, and it becomes a lot quicker to identify these. That's 90% of the job, looking at browser versions after that is easy, and doesn't need to go in comments.

[ddbeck]

A complementary approach is to add dates to the individual keys in the generated dist wherever it doesn't match the Baseline low date (after override, if any).

This way, any key with a comment after it is one that changes something, and it becomes a lot quicker to identify these. That's 90% of the job, looking at browser versions after that is easy, and doesn't need to go in comments.

Can you show some example YAML of what this might look like (even with fake dates etc.)? I'm having a hard time visualizing it.

[foolip]

Hmm, trying to make an example reveals a problem. Just the date usually won't help, it's often unchanged.

If we imagine that computeBaseline() instead picked the earliest dates and versions, the something like this:

name: Visual viewport API
spec: https://drafts.csswg.org/cssom-view-1/#visualViewport
status:
  baseline: high
  baseline_low_date: 2021-08-10
  baseline_high_date: 2024-02-10
  support:
    chrome: "61"
    chrome_android: "61"
    edge: "79"
    firefox: "91"
    firefox_android: "68"
    safari: "13"
    safari_ios: "13"
compat_features:
  - api.VisualViewport
  - api.VisualViewport.height
  - api.VisualViewport.offsetLeft
  - api.VisualViewport.offsetTop
  - api.VisualViewport.pageLeft
  - api.VisualViewport.pageTop
  - api.VisualViewport.resize_event # Chrome 62
  - api.VisualViewport.scale
  - api.VisualViewport.scroll_event # Chrome 62
  - api.VisualViewport.width
  - api.Window.visualViewport

This is the information I'd like to look at while iterating on a feature to get the browser versions right, but this doesn't feel like the right solution.

Perhaps we could instead group compat features by the browser versions they were introduced in? If we've computed a support object for each BCD key, we could turn that into a compact string and use as a comment between blocks with the same support:

name: Visual viewport API
spec: https://drafts.csswg.org/cssom-view-1/#visualViewport
status:
  baseline: high
  baseline_low_date: 2021-08-10
  baseline_high_date: 2024-02-10
  support:
    chrome: "61"
    chrome_android: "61"
    edge: "79"
    firefox: "91"
    firefox_android: "68"
    safari: "13"
    safari_ios: "13"
compat_features:
  # Chrome 61 / Edge 79 / Firefox 91 / Firefox Android 68 / Safari 13
  - api.VisualViewport
  - api.VisualViewport.height
  - api.VisualViewport.offsetLeft
  - api.VisualViewport.offsetTop
  - api.VisualViewport.pageLeft
  - api.VisualViewport.pageTop
  - api.VisualViewport.scale
  - api.VisualViewport.width
  - api.Window.visualViewport
  # Chrome 62 / Edge 79 / Firefox 91 / Firefox Android 68 / Safari 13
  - api.VisualViewport.resize_event
  - api.VisualViewport.scroll_event

I'm assuming some simplification across desktop and mobile where the numbers are the same.

[foolip]

If we implement this, I'd like to review the features with the largest difference between first and last version for each browser, even if that doesn't end up affecting the Baseline low date. #840 is one such feature, where webkitEntries shipped in Chrome 22, but the overall feature says Chrome 86.