Just to clarify the proposal... How does writing-mode play into this (if at all)?

E.g. in your example at the end, would anything need to work out differently if the flex item had an orthogonal writing mode? Or would it still end up choosing the same final physical axis?

(and relatedly: in practice, does this only change behavior for abspos flex children?)

As a concrete example:

<style>
  .containing-block { position: relative; }
  .abspos { position: absolute; align-self: start; justify-self: end; }
</style>

<div class="containing-block">
  <div style="flex; align-items: center;">
    <div class="abspos"></div>
  </div>
  <div style="flex; flex-direction: column; align-items: center;">
    <div class="abspos"></>
  </div>
</div>

Should the two "abspos" go in the same direction?
What happens with align-self: initial?
What happens with inset:0?
Note that containing-block could have a different writing-mode+direction of the static-container.

The align-self and justify-self properties initialize to auto, which for absolutely-positioned elements does not reference the container`. https://www.w3.org/TR/css-align-3/#valdef-justify-self-auto

We might have a compat problem here that we need to address for flexbox particularly, but the ideal behavior here is that align-items has no effect on abspos descendants.

Looking more closely here, it appears that the current behavior of browsers is just to apply the "inheritance" of *-self for the purpose of calculating the static position (of abspos flexbox children). I can't get any browser to pay attention to *-self properties for the normal alignment of the abspos, so I presume that's not implemented at all yet and we can rely on the current spec explicitly not looking up at *-items when determining its behavior. (See https://jsfiddle.net/dyp9uwea/.)

So this probably just needs (yet another) quirk inserted into the abspos flex children staticpos determination.

The align-self and justify-self properties initialize to auto, which for absolutely-positioned elements does not reference the container`. https://www.w3.org/TR/css-align-3/#valdef-justify-self-auto

This isn't clear from the spec to me - can you quote the place where this is mentioned?

We might have a compat problem here that we need to address for flexbox particularly, but the ideal behavior here is that align-items has no effect on abspos descendants.

Hmmm - we have a larger issue here then. Currently align-items for both grid and flex (interoperably across all engines) affect the static position. I believed that we were going to keep the align-items, and justify-items behaviour for grid.

Looking more closely here, it appears that the current behavior of browsers is just to apply the "inheritance" of *-self for the purpose of calculating the static position (of abspos flexbox children). I can't get any browser to pay attention to *-self properties for the normal alignment of the abspos, so I presume that's not implemented at all yet and we can rely on the current spec explicitly not looking up at *-items when determining its behavior. (See https://jsfiddle.net/dyp9uwea/.)

Right that's what I was looking at implementing - as well as the staticpos rectangle alignment. I suspect we aren't compat constrained in the align-self / justify-self properties (but are compat constrainted with the align-items / justify-items ).

(and relatedly: in practice, does this only change behavior for abspos flex children?)

Abspos flex children in a column flexbox.

This isn't clear from the spec to me - can you quote the place where this is mentioned?

The first sentence of the "auto" definition: "Behaves as normal if the box has no parent, or when determining the actual position of an absolutely positioned box."

I see thanks.

Hmmm - we have a larger issue here then. Currently align-items for both grid and flex (interoperably across all engines) affect the static position. I believed that we were going to keep the align-items, and justify-items behaviour for grid.

E.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10629

Ah, right, our wording actually directly says that by referencing "actual position". We intended that static position would use the normal rules, which means inheriting from the parent's *-items properties. We should make that clearer, tho.

In full, this seems to be where we're at:

*-self applies to abspos:

• for non-static, it aligns within the inset box
• for static, it aligns within the staticpos rectangle

*-self: auto on abspos:

• for non-static, it ignores *-items of parent
• for static, it takes *-items of parent

staticpos rectangle:

• for grid children, is
  • the content edges of the grid container in both axes (or of the grid area)
• for flex children, is
  • the cross-axis content edges of the flex container
  • the main-axis margin edges of its hypothetical position
• for block children, is
  • zero-height and at the hypothetical position in the block axis
  • more or less sized to staticpos containing block in the inline axis (modulo floats, etc.)

Edits needed:

• Clarify the above
• Be clear and consistent in defining and using “static position” and “static position rectangle”. (Just checked in a2e50cb to that end.)

The CSS Working Group just discussed [css-align] *-items properties might need to resolve directions early, and agreed to the following:

• RESOLVED: Take the changes listed in https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091

@bfgeek We believe we've fixed all of this in the specs, let us know if anything seems to still be off?