-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-align] align-self / justify-self on abspos elements isn't back compatible? #7599
Comments
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. |
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.) |
The CSS Working Group just discussed
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//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 |
Consider:
https://drafts.csswg.org/css-align-3/#justify-abspos
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
The text was updated successfully, but these errors were encountered: