Treat BCD ranges as exact versions, hiding "≤" annotation

[foolip]

mdn/browser-compat-data#9350 is an example of the display of these entries being confusing, with ≤79 being interpreted as "supported in 79 and earlier", instead of the intended "support in 79 and later, support before 79 unknown".

All allowed versions are here:
https://github.com/mdn/browser-compat-data/blob/fdf38f58f9e660034de914ccb82d34cfd82d91a8/test/linter/test-versions.js#L17-L26

As of BCD 3.2.0, the number of entries for each are:

• npm run traverse edge all ≤18 → 375
• npm run traverse edge all ≤79 → 862
• npm run traverse ie all ≤6 → 34
• npm run traverse opera all ≤12.1 → 1191
• npm run traverse opera all ≤15 → 11
• npm run traverse opera_android all ≤12.1 → 1188
• npm run traverse opera_android all ≤14 → 15
• npm run traverse safari all ≤4 → 35
• npm run traverse safari_ios all ≤3 → 42
• npm run traverse webview_android all ≤37 → 1629

The most recent of these is Edge 79, released on 2020-01-15, followed by Edge 18 on 2018-10-02. Most are much older, however, for example Opera 12.1 was released on 2012-11-20.

These ranges are very helpful for improving the accuracy of BCD step-by-step without requiring digging into the ancient history of every feature. However, my hunch is that it would be a net positive for MDN readers if this uncertainty is simply hidden.

[ddbeck]

I want to give my +1 to this idea.

I've been mulling this over a while and I think this is a reasonable way to put an end to the confusion around ≤ values. I think it's possible that reporting somewhat wrong values is going to be more productive than the confusing thing we've been doing to date.

Right now, if a reader knows the real, non-ranged value for an ≤ entry, then they need to a) correctly decipher the meaning of ≤ (which we know is a challenge), b) know that we want to record that real value, and c) actually report an issue or open a PR.

If we simply report a somewhat wrong value, I think we're much more likely to provoke actionable issues against BCD. The reader only needs to know that the number is off and to report the issue.

[Elchi3]

I agree so much that I opened #3494

[hamishwillee]

Late to the party, but perhaps another alternative would have been to use an alternative rendering. For example, render "≤37" as 37+ or 37 (and later). Certainly omitting it is better than the confusion.

I guess it doesn't matter now that the data is getting very close to "fully accurate". I'm only commenting because I saw mdn/content#10899