[css-align] align-self / justify-self on abspos elements isn't back compatible?

[bfgeek]

Consider:

<div style="direction: ltr; width: 100px; border: solid lime 3px; position: relative;">
  <div style="direction: rtl; margin: 20px; border: solid hotpink 3px;">
    <img style="position: absolute; width: 10px; height: 10px; background: cornflowerblue;">
  </div>
</div>

https://drafts.csswg.org/css-align-3/#justify-abspos

justify-self Axis | The block’s containing block’s inline axis.

Today the static-pos of will be on the right - however I think what the current spec text is suggesting is that it'd be on the left? I.e. justify-self:auto -> justify-self:normal -> justify-self:start

I suspect this isn't intentional - likely "normal" needs to be interpreted as what the natural alignment of the static-pos rect is.

cc/ @tabatkins @fantasai

[tabatkins]

This appears to be pretty much undefined, afaict. While we specify the axis that the property operates in, we don't specify what writing mode/etc the staticpos rectangle uses. I think it's reasonable for it to take its directions from the parent, yeah - that matches the "what it would do if it wasn't positioned" intention. The fact that we have backcompat on that behavior just makes the answer obvious.

[fantasai]

justify-self: start is defined to use the writing mode of the container: https://www.w3.org/TR/css-align-3/#positional-values

I think it's good to bring this up though: for static positioning, we probably want to use the writing mode of the static position containing block to resolve both the directions and the axes. (That'll also solve our backwards-compat concerns with Flexbox in a self-consistent way.)

[css-meeting-bot]

The CSS Working Group just discussed [css-align] align-self / justify-self on abspos elements isn't back compatible?, and agreed to the following:

• RESOLVED: Use the writing mode of the parent's formatting context for staticpos
• RESOLVED: Align justify axis of non staticpos use writing mode of their containing block

The full IRC log of that discussion

<dael> Topic: [css-align] align-self / justify-self on abspos elements isn't back compatible?
<dael> github: https://github.com/w3c/csswg-drafts/issues/7599
<dael> fantasai: This is how do we resolve the axis it operates in. When staticpos we use axis as defined by the formatting context, the parent formatting context
<dael> fantasai: I think we can resolve on that and then address what to do for non-staticpos
<dael> astearns: Prop: Use the writing mode of the parent's formatting context for staticpos
<dael> astearns: Sounds like that's what we need for web compat?
<dael> iank_: I don't have data but I would wager people are relying on this working as is
<dael> astearns: Obj?
<dael> RESOLVED: Use the writing mode of the parent's formatting context for staticpos
<dael> fantasai: Follow-up for non staticpos. Spec says for abspos you resolve justify and align based on containing block's writing mode. Rather than checking parent. Reason is pulling from deeper context and trying to layout with other things should use same reference axis
<dael> fantasai: That's why we defined it that way. Is that fine or do something different?
<dael> iank_: Broadly fine. For clarification if you've got a line item on containing block does that effect out of flow element?
<dael> fantasai: If out of flow is not staticpos it does not look at align items on anything
<dael> iank_: Makes sense
<dael> iank_: The quirk that falls out is align-self:center if you're staticpos in one axis and not in the other axis it will effect both axis
<dael> fantasai: Yeah. I think it's a little weird but anything else is weirder in more common cases
<dael> iank_: Yeah, fine with that.
<dael> fantasai: Align justify axis of non staticposuse writing mode of their containing block
<dael> RESOLVED: Align justify axis of non staticpos use writing mode of their containing block
<dael> iank_: Clarification- when doing this you need to say staticpos in a particular axis
<dael> fantasai: Yeah

[fantasai]

@bfgeek We've completed the edits for this add https://github.com/w3c/csswg-drafts/issues/7612 ; Let us know if anything still needs fixing?