Add missing CSS flexbox property values

[Elchi3]

Towards #30410

According to the Collector, support goes a long way back. I assume these values have been introduced with the initial Flexbox implementation which would make sense given BCD originally didn't have initial CSS values as sub features. They were mass-added by Vinyl in 2025.

Also, these Flexbox sub-features probably weren't added back then because the structure is not simple: There is nesting going on here where values sit below flex_context and grid_context. You can also see this in the compat table on MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/align-content#browser_compatibility

I think we want the following structure, but it would be good to confirm it before I proceed with other CSS properties. Is it correct to put all these values under flex_context?

• css.properties.align-content:
  • block_context
  • flex_context
    • baseline
    • center
    • end (new from split)
    • first baseline
    • flex-end (new)
    • flex-start (new)
    • last baseline
    • safe (new from split)
    • space-around (new)
    • space-between (new)
    • space-evenly
    • start (new from split)
    • stretch
    • unsafe (new from split)
  • grid_context
  • multicol_context
  • normal

Alternatively, I guess, we could flatten this all out, leading to a few moves plus adding the missing values. That would mean less work for me on the Collector side, as I still have to teach the Collector that these values can be found in subtrees (flex_context in this case, grid_context in other cases).

What do we think?

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[ddbeck]

So I've never been particularly fond of the flex_context etc. hierarchy, since there's no one key that represents the "this value participates in the cascade as a valid value" support case. I kinda think the "right" thing to do — especially if the Collector is not going to actually verify the applicable contexts — is to invert the structure to reflect how we handle these behaviors in other contexts, even though it involves more keys:

• css.properties.align-content
  • foo
    • block context
    • flex context
    • grid context
    • multicol context
  • bar
    • block context
    • flex context
    • grid context
    • multicol context

😬

[Elchi3]

I can look into inverting this and then see how the collector might be able to test things, but I’m not sure if it is possible.

Per your proposal css.properties.align-content.foo would then have "whatever came first" as its data? or no data for the value directly and just data under the context keys?