Choose a guideline for descendant flag data

[ddbeck]

Prompted by #6465 and #6433 (comment), we do not have a consistent way of considering flag data for features which are descendants of a feature also behind a flag.

Or, more visually, consider a structure like this:

• SomeObject
  • SomeObject()
  • someMethod()

If SomeObject is behind a flag, should SomeObject() and someMethod() duplicate the flag data of SomeObject? If the data should be duplicated, by what mechanism?

---

Blocks: #8947

[ddbeck]

Some reviewers, such as myself, have been supposing that a feature behind a flag implicitly puts every descendant feature behind the flag. I described my thinking on this in more detail in this comment #6465 (comment). I concede this might be a source of confusion in some consumer use-cases (e.g., an MDN page for some subfeature may not show that the parent feature is gated by a flag because that's on another page), but it great simplifies maintenance. When a feature is no longer behind a flag, only the parent feature data needs to change.

Other reviewers have been doing something else, but I can't say what their thinking is.

Possible solutions that have occurred to me:

1. Always inherit: Set a guideline requiring that features must duplicate any flag data from its ancestor features (i.e., every feature must independently record any flags required to access that feature even if those features a predicate to the feature in question). Plan work to: a) add linting to catch inconsistently flagged data, b) add migration scripts to fix inconsistently flagged data and c) add a fix script to cascade new flag data.

2. Never inherit: Set a guideline requiring that features must not duplicate flag data from its ancestor features (i.e., a feature must only report the flags which apply to itself and its descendants, but not its ancestors). Plan work to a) add linting to catch inconsistently flagged data and b) add migration scripts to fix inconsistently flagged data.

3. Dynamically inherit: Set a guideline requiring that features must not duplicate flag data from its ancestor features, but dynamically inline flags into descendant features (i.e., when ingesting JSON files, cascade flags to subfeatures automatically). Plan work to a) add linting to catch inconsistently flagged data, b) add migration scripts to fix inconsistently flagged data, and c) add code to dynamically inline flags into descendant features.

   There could be variations on this approach, too, if determining whether a feature has inherited a flag becomes too complex or over-inflates the data (e.g., a sort of meta flag that says, more or less, "parent feature may X require a flag").

I prefer the second and third options over the first, though I think all are acceptable. The status quo (which appears to be anything goes) is not working for me.

[a2sheppy]

I would like to amend things so that most fields in a record can be set to "inherit" to inherit the parent node's value. This would be permitted for things like flags, version_added, deprecated, standards_track, and experimental, for example.

Then, by default, values would not be inherited, but they could be configured to do so when appropriate.

[queengooborg]

I ran into this when working on #6679. Personally, I feel that subfeatures should never inherit flags, as I feel that it's just duplicating data over and over again, where we only need the data to be in one location: the parent feature. @foolip made a good argument about how the tables render on the MDN web docs, of how the parent feature will display the version when the flag is no longer needed but its subfeatures display an earlier version -- however, I feel that's more of a table display issue (not to mention that it's the same case for prefixes and alt. names).

[foolip]

Thanks for pointing this out, @vinyldarkscratch. I had always assumed a certain interpretation of flag data and never stopped to wonder how other people interpret it. My interpretation was: if you traverse all of BCD and delete any entries with a flags property, and then set version_added to false if there are no entries left, then you get a representation of what's shipping in browsers with their default settings.

Although I don't enjoy dealing with flag data when just trying to make the shipping-by-default data accurate, the always inherit is the one that matches my assumed interpretation. For any of the other options, what are the rules that data consumers must apply to discard flag data and be left with shipping-by-default data?

Aside: I don't think is very similar to prefixes and alternative names. Those modify the name of that specific entry, making it possible to represent both, PrefixedThing.method and Thing.prefixedMethod. (There is a problem of interpreting the data when there's prefixing at both levels though: Do all combinations exist? Not always. But that's not a big problem.)

[foolip]

To spell out the problem of applying flag data to subfeatures, take this situation:

• The parent feature has a { "version_added": 30, "flags" ... } entry
• The child feature has a { "version_added": 35, "version_removed": "40, "flags" ... } entry

What is the correct interpretation of this? Is the data impossible (failing the lint) because there's a contradiction, does the child support statement plainly override the parent feature, or should statements be merged?

I fear the answer will be that some merging has to happen, and that this is not at all trivial in the face of multiple support statements at both levels.

I might suggest this framework for resolving this issue:

• Decide on what a reasonable rule the data consumers have to apply to get the with-flags and shipping-by-default variants of the data
• Apply those rules as part of the lint and ensure consistency in both views of the data
• See if we're happy with the changes we would have to make to appease the lint

My guess is that some rules would require larger changes than others, and we might find that one assumption is more common than another in the data.