Box alignment features are hidden by current organization

[mirisuzanne]

Currently all the box-alignment features are hidden under their respective contexts.
The css.properties.align-self.position_absolute_context key is in the absolute positioning feature, and same with flexbox/grid/etc. Only "align-content in block layouts" has it's own data visible.

The most immediate problem with this is that we can't see the multi-browser support that exists for alignment in absolute positioning. At the very least, position_absolute_context alignment keys deserves to be a feature.

At a high level, I think we lose out by not treating "box alignment" as a top level feature of CSS. I know it's historically been taught as 'part of' different layout systems - but authors have consistently found that confusing. The reality is we're close to having it everywhere, with a unified syntax we can teach and use across layouts.

[ddbeck]

Thanks for opening this issue, @mirisuzanne. I'm very curious about ways in which the definition of features does not (or should not or does!) align with developer expectations.

The most immediate problem with this is that we can't see the multi-browser support that exists for alignment in absolute positioning. At the very least, position_absolute_context alignment keys deserves to be a feature.

Can you talk about what the absolute-positioning feature is missing or over-fitting on? Or is this a suggestion about the underlying browser compat data itself, that it should somehow record the existence of different layout modes distinctly from whether or not certain properties engage with that mode?

[mirisuzanne]

There are several keys that have to do with alignment properties in an absolute positioning context. They are all labeled with position_absolute_context keys. The underlying data/keys look good to me, but all of those are grouped with the absolute-positioning feature: https://github.com/search?q=repo%3Aweb-platform-dx%2Fweb-features%20position_absolute_context&type=code

But absolute positioning generally is listed as baseline high, and these keys are fairly new. They should probably get their own grouping to expose their 'limited' support. That's already being done for align-content in a block context: https://github.com/search?q=repo%3Aweb-platform-dx%2Fweb-features+block_context&type=code

Breaking those *-self.position_absolute_context keys into a new feature would be a big help.

[mirisuzanne]

re: aligned expectations, I think there's two things to consider that are sometimes at odds:

• "how have authors historically thought of this" is sometimes useful
• but so is "how could authors more clearly think of this moving forward"

Because new features in CSS can often re-frame old features.

[jamesnw]

I'm the one who proposed the initial sorting in #2188, but I agree that "Box alignment of absolute positioned elements" should be a separate feature from absolute positioning. I'll make a PR for this.

I think a box alignment feature would also be useful- I'll play with that and see if one makes sense there.