`support_statement` syntax about browser-compat-data

[stephaniehobson]

I think this conversation is a bit bigger than adding and removing features. Here is some data to test our assumptions against:

16

• feature added behind a flag

21

• footnote: only allowed in sandboxed iframes

22

• feature is restricted to secure contexts
• feature no longer restricted to sandboxed iframes

23

• feature is no longer behind a flag

25

• feature removed

The easiest and most understandable approach I see is for each support statement to be a complete snapshot of the browser's support at that point in time. Which means the support statements for the above would require versions 21 and 22 to also identify that they are behind a flag and for 23 to identify that it must be in a secure context.

I agree simple_support_statements should be ordered (OMG yes)

I think we should allow true/false/null if it is the only or first in an array (so the above example could also have a false in the list prior to version 16)

[Elchi3]

There are a lot of things in this issue and we decided to resolve them once we have more experience and use cases. I want to bring a case to the table that illustrates that overlapping versions are OK.

(1) Should it be OK for ranges to overlap

Imo, yes, given e.g. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/includes

I would translate it to this structure:

"firefox": [
  {
    "alternative_name": "contains",
    "version_added": "18",
    "version_removed": "48"
  },
  {
    "version_added": "40"
  }
],

This disagrees with

if you supply an an array of simple_support_statement objects, only the last one is allowed to include version_removed: the others are implicitly ended by the start of the next one.

For compatibility, both names were supported for a while, so the ranges overlap.

(2) Should it be OK for ranges to include gaps:

I haven't seen anything like this yet, if you encounter this, let us know here.

(3) Do we assume that the ranges are ordered?

I think ordering makes a lot of sense. My feeling is that the earliest version_added should be first.

[Elchi3]

I'm not sure there is anything actionable left here.
The redesigned tables, when encountering an array of support statements, will use the first statement to display in the cell and then have the historical or extra support statements in a collapsed section. I think that's quite nice as it shows you the most relevant support version first and if you need the details you can expand and see other support ranges with limitations like prefixes etc.