Add flexbox compat features and status

[ddbeck]

This adds features and simplified support status to flexbox. This is probably the first great example of messy data creating issues.

Some issues I encountered here:

• I skimmed through the flexbox spec and wrote a list of expected BCD features. I commented out the ones that don't exist in BCD. It's interesting to see what keys do and do not exist in BCD. The two exceptions I deleted outright were css.properties.flex-basis.content and css.properties.flex-basis.fit-content, which seem to be distinctly later additions. It's interesting to consider whether we ought to complete the "missing" subfeatures, or to do as BCD does: assume they're supported with the parent feature.

• The {flex,grid}_context pseudo-groups in BCD are quite challenging to deal with. I once opened Regularize feature namespaces for CSS, HTML, HTTP, and JavaScript mdn/browser-compat-data#13804 to address this and it was "fixed" by adding more compat features, instead of fixing the muddled structure (e.g., css.properties.align-content contains a __compat object). But I still don't get what the data really means: what could css.properties.align-content represent, independently of flexbox and grid? Are all of the subfeatures of flex_context exclusive to flexbox (since none appear beneath grid_context)?

• Firefox has lots of weird notes—something to do with multi-line flexbox—especially css.properties.flex-direction. Thankfully this is all in the rather distant past so it's not critical if we're off by even dozens of releases, but it's a good example of the kind of thing that would be very challenging to untangle for a more recent feature.

[foolip]

This and the below are quite a lot later than https://caniuse.com/flexbox. What are the newest part of the feature that cause the whole feature to look new here?

[ddbeck]

The key thing affecting the date is Firefox 81's full support for flex-direction. Before that it has partial support. That feature alone determines the baseline date (without it, it would be determined by Edge 80's release date).

For the individual browsers' differences with caniuse, let's look at each in turn. In general, I ignored prefixed-only and partial implementations, but this has a smaller effect than you might guess.

For Chrome, most of the features lined up with caniuse's 29+. The exceptions were:

• Chrome 57: css.properties.align-content.flex_context.stretch, css.properties.align-self.flex_context.stretch, css.properties.justify-content.flex_context.stretch
• Chrome 36: css.properties.align-self.flex_context

For Edge, both the stretch and baseline values push it above caniuse's Edge 12 to Edge 79. I also treated ≤79 as Edge 79, though I don't think it would make a difference to the sum of the features.

For Firefox, most of the features were roughly in line with caniuse, though caniuse says that before Firefox 28 is partial, while BCD uses notes with no partial flag. Beyond Firefox 28, the divergences from caniuse are:

• Firefox 52: stretch values, again
• Firefox 81: css.properties.flex-direction stops being a partial implementation. This one is messy, with a partial and notes.

For Safari, caniuse shows a green indicator for prefixed implementations starting at Safari 7. Waiting for the unprefixed versions pushes most of the features to Safari 9; I think that's the only thing we can do before sorting out ways to annotate results.

Taking this all together:

• If Firefox's data for flex-direction is wrong or misleading, then corrections might lead to the overall baseline date back to Edge 80's release, about 8 months earlier.
• If that were true and EdgeHTML had more complete flexbox support, then it's possible the date could shift backwards even further, to before 2020.
• I'm not a subject matter expert, but it's possible that stretch is a separate group. If it were moved to another group (and nothing else changed), then flexbox would show an earlier version for Chrome (36), but wouldn't otherwise alter the results.

[foolip]

Alright, so clearly there's a lot of nuance here, a cluster of granular CSS properties and values, many of which come with a complex history of partial support, notes, etc.

I'm happy with the explanation of the versions you've given, and the only issue I can foresee is if any consumer uses the version numbers and displays them to users. There are multiple ways we can address that, but for now I think we should just proceed with the manually determined versions you have here.

[foolip]

On flex_context and grid_context, I think that distinction will soon fade into the background. It made sense for the gap property in particular, but going forward I assume that new CSS properties will be supported in Flexbox and Grid. I think that at some point it will make sense to collapse these and treat it as partial_implementation. However, doing that will make it harder to interpret the data to determine support for Flex and Grid overall. So let's just deal with the current BCD structure for this entry.