Also, if you’re gonna do this, at least change version_added to include the older pref data which you are removing.

I've updated the version removed version numbers to be inclusive. Thanks for that. I don't agree with changing the version added numbers to be inclusive of the older pref. That would potentially be more confusing.

I was very close to not including pref information at all. We've been asked by so many people to not include it after the feature is enabled, as noone really cares.

Hi @chrisdavidmills, thanks for starting this PR. I could use your help though, as I can't seem to square your description and the diff. Here's what I'm seeing:

• The existing data said and says, from version 63, it's supported by default (no pref needed).
• The existing data said, from version 59 to 65, it was supported behind a pref. You amended the data to capture the change in default: before version 63, it was supported but behind a pref (the implication being that the pref exists before 65, but defaults to false before 63). You made this change to prevent confusion created by the 63-65 overlap.
• The existing data said, before version 59, it was supported under a different set of prefs. You deleted this. I'm not sure why. I suspect it's because it's old and behind a pref, not because it's wrong, but I'm not sure.

Assuming that's right, I think there's a couple points I'd like to address:

• The change in data makes sense here, building a timeline of most-expansive support, not a timeline of the existence of prefs. 👍
• I'd like to be cautious about deleting the data, assuming it's correct. If we're deleting correct data because of prefs, that's OK, but I'd like to talk about why and how we're doing this. If you're deleting it because it's wrong, then carry on. 😄

Hi @ddbeck ! So you are correct on all counts here.

As per the one point of contention — the initial pref information was correct (the first set that I deleted), but I felt that it made the data unnecessarily uncomplicated. The Google Chrome folks have mentioned a number of times that they feel it is completely pointless including pref information after the feature has been enabled. Because noone cares or will find it useful.

However, I guess this is a conversation to have with a wider audience, not a decision for me to make on the fly. If you'd rather I added it back in, I will do.

I think we need to make a call whether or not we want to remove any "behind a flag" data whenever a feature becomes available by default (or a new flag situation arises). Let's call these flags "dead flags" as there are flags the still very much control features and aren't just pure historic. I think we could make this removal a rule as the table display on MDN would be simplified and I am not aware of other data consumers really caring about "dead flags". A bit of implementation history would be lost, but it seems like no one is interested in that data and this repo doesn't have a goal of preserving all implementation history details of browsers.

The other option would be to be correct in the data about this and to hide "dead flags" in the MDN table displaying logic, but that requires making that compat macro more complicated and a few engineering hours investment.

I will post about this on discourse and/or in an issue an then we will make the call and enforce the "dead flag" removal throughout the repo (with a new linting rule possibly).

Sorry, @Elchi3 I opened #3318 before I saw your comment. I think we're on the same page that a decision is needed, but let me know if I should move my commentary to Discourse.

@chrisdavidmills in the interest of getting this PR merged, would you mind restoring the data you removed? That lets us defer the decision about removing flagged data.

@ddbeck OK, done.