@ddbeck @Elchi3 I'd love your thoughts on this. I put this together while thinking about #10653 (comment), and this stricter lint would cause some changes in that PR to fail.

Since MDN now drops the ≤ I think BCD should require the data to be sensible even if ignoring ranges.

I think this makes sense. I definitely didn't think about this when we changed the MDN rendering. Good catch!

@Elchi3 do you feel like reviewing?

I'm kinda neutral on this idea, though I won't stand in the way of it. I agree that it's not good when the data looks like this, but it's not clear to me that this is a presentation problem, rather than a problem with the data itself.

So, in terms of the data this makes things only stricter by disallowing the following case, right?

version_added: "≤37"
version_removed: "37"

It is valid data but by disallowing it would then prompt the BCD author to avoid "≤37" leading to a real value that doesn't involve "≤" (which is better data).

Other side effects here? If not, then I would say we should go with this.

Other side effects here? If not, then I would say we should go with this.

The one I can think of is someone adding less-accurate data (e.g., setting false instead) to satisfy the linter. Though I guess there won't be that many people working on resolving ranged values anyway, and they all know better, so maybe it's not worth worrying about. 🤷‍♂️ I guess we can proceed on this.

@Elchi3 there's also cases like this that this would disallow:

version_added: "≤37"
version_removed: "4.4"

Thanks @Elchi3!

@vinyldarkscratch now that this is landed, it would be good to revisit that WebView SVG weirdness and resolve it in a way that doesn't break this lint rule.