Remove unsupported browser versions from tools/feature_matrix.py

[sbc100]

No description provided.

[juj]

Is there a benefit to removing these?

I think there is value in keeping the version numbers, even if/when those are older than what we support. This is since it serves as a positive documentation to highlight that we have identified what the min version number is.

If we remove the numbers, it is not obvious to the reader if the version are absent maybe due to not having been precise about investigating the exact versions in all cases.

When the numbers are there, it lets one reason "Oh, sign-ext was a very old extension and not something new."

[sbc100]

Is there a benefit to removing these?

I would like to completely remove references to browser versions that we don't support.

By my logic it doesn't seem useful to keep information here that we never use.

This change allows me to quickly look a feature and see which browser engines are currently stopping us from enabling it by default.

If we keep the redundant information then I need to manually check each version to find this out.

I think there is value in keeping the version numbers, even if/when those are older than what we support. This is since it serves as a positive documentation to highlight that we have identified what the min version number is.

If we remove the numbers, it is not obvious to the reader if the version are absent maybe due to not having been precise about investigating the exact versions in all cases.

The information in this file should come directly from caniuse of the wasm features page, and when it doesn't I think a comment is the best way to handle that. i.e. "# Note: we don't know the precise version here".

When the numbers are there, it lets one reason "Oh, sign-ext was a very old extension and not something new."

Conversely, after this change, I can easily see "Oh, sign-ext was a very old extension and not something new, because only safari is listed here, meaning its supported by default of most engines", its just a matter of learning that fewer entries means wider support (less restriction).

[sbc100]

This change allows me to quickly look a feature and see which browser engines are currently stopping us from enabling it by default.

Specifically I think its useful to be able to see at a glance that "If we just bump out min safari version we could completely remove support for engines without feature X".

[juj]

This change allows me to quickly look a feature and see which browser engines are currently stopping us from enabling it by default.

Oh, sign-ext was a very old extension and not something new, because only safari is listed here, meaning its supported by default of most engines

That is a bit awkward tacit workflow knowledge that is not discoverable by others. One will just need to be "in-the-know" to follow that is what the absence of information here means.

When there is code like

  Feature.OFFSCREENCANVAS_SUPPORT: {
    'firefox': 105,
    'safari': 170000,
  },

then only to you as a core developer the above code will speak out that "everything that was not mentioned here must have been < the min version that we support".

I think it would be better to sunset full features when all browsers support the feature, so we can remove a full feature block.

The cleanup that is achieved here does not seem to be particularly effective, and also in this PR there then needs to active code to paper over the missing fields.. less active code, more passive data in general results in a smaller cognitive load, since the handling is then more uniform.

[sbc100]

OK, fair enough, I'll abandon this. I was only micro cleanup anyway.