[css-align] Center alignment can be improved

[tabatkins]

(Separating out from #1432 (comment).)

Ian believes we can improve on the center-alignment rules.

In particular, he believes that the correct answer is to find the smaller of the start- and end-aligned sizes, then double that, aligning it to the abspos containing block edge that was chosen. This lets it fill out the abspos containing block as much as it can while still remaining centered on one of the "significant edges" of the staticpos containing block.

This is apparently what Edge does. Everyone else does some other "entertainingly wrong" (Ian's words) behavior.

FYI - I added two tests with this behaviour here: wpt.fyi/results/css/css-position?label=master&label=experimental&aligned&q=position-absolute-center which EdgeHTML did pass (doesn't as written as used inline-size, block-size properties).

[tabatkins]

@bfgeek I've forgotten why I found your argument for this compelling when you presented it to me. Can you provide some example of the behavior, and why the other behaviors are bad?

[tabatkins]

I wrote down Ian's suggested behavior wrong; his intention is to essentially let it grow in both directions from the center of the staticpos containing block, stopping when it hits one of the edges of the abspos containing block.

The mechanics, then, are find the smaller of the distances from the center of the staticpos containing block to the abspos containing block edge, then double that and stick it to the abspos containing block edge that was selected, then center the item in that space. This makes sense!

[fantasai]

OK, we made edits for this (and updated the diagram). See https://drafts.csswg.org/css-align-3/#abspos-sizing Agenda+ to discuss/approve.

[mrego]

We're somehow "overflowing" the static containing block, would overflow-position values safe and unsafe have any effect?

I'm also wondering what's the use case, and why we want to grow out of the static containing block when you use justify-self: center on an abspos element that uses the static position.

[bfgeek]

@mrego By default absolute/fixed positioned object always can grow outside the static containing block (from CSS21).

You can become start/end aligned depending if the absolute/fixed positioned object is within an LTR/RTL context. This normalizes the behaviour for "center" with how this currently works.

[mrego]

Got it now, it probably makes sense yeah.

[css-meeting-bot]

The CSS Working Group just discussed Center alignment can be improved, and agreed to the following:

• RESOLVED: Accept the text in current ED and open bugs on browsers to implement.

The full IRC log of that discussion

<heycam> Topic: Center alignment can be improved
<heycam> github: https://github.com//issues/4659
<TabAtkins> https://drafts.csswg.org/css-align/#abspos-sizing
<heycam> TabAtkins: the diagram shows how alignment affects the available space for sizing static positioned abspos elements
<heycam> ... you have the abspos containing block
<heycam> ... you have the parent of the abspos (the static pos containing block)
<heycam> ... and you have the abs pos child
<heycam> ... it's statically positioned in the horiziontal axis
<heycam> ... we look at justify-self for alignment
<heycam> ... historically we had one rule to do this, based on direction
<heycam> ... here we're letting you specify that manually
<heycam> ... if start aligned, it does what you expect
<heycam> ... the space to align into starts on the start edge where teh static position is, and goes to the end of the abspos containing block
<heycam> ... it sits in ths same spot, but grows to where 0 would be
<heycam> ... if you'are end, you do the opposite, growing to where left:0 would give you
<heycam> fantasai: this is the behavior fro RTL text
<heycam> TabAtkins: how do you do cetner?
<heycam> ... previously the spec said you use this box [points to blackboard]
<heycam> ... you can't get bigger than the abspos containing block, which is weird because the other alignments can
<heycam> ... Ian's suggestion is to let it grow from both sides until one side would hit the edge of the abspos containing block
<heycam> ... it's cnetered in the expected space, but gets as large as it can
<heycam> iank_: this is EdgeHTML's behavior
<heycam> ... we'll have this when we pick up our new flex impl
<heycam> ... we've added some tentative tests
<heycam> TabAtkins: nobody currently center aligns according to the current spec
<heycam> ... I've edited this into the spec
<heycam> dbaron: this is the width you end up with auto width
<heycam> TabAtkins: if you have enough content
<heycam> fantasai: fun side effect, this makes it possible to interpolate between all three values
<heycam> ... since it's between the other two values
<heycam> iank_: this fell out beacuse we were adding static center positions in our new arch, and this was the obvious thing that fell out
<heycam> ... was relatively easy for us to do
<heycam> dbaron: I didn't realise we implemented this section of the spec at all, I'm ok with this
<heycam> cbiesinger: we only implement this for flex boxes?
<heycam> iank_: we get the available size more wrong
<heycam> cbiesinger: but we only do this if the parent is a flex box?
<heycam> iank_: yes
<heycam> ... only applies in implementations with flex boxes
<heycam> dbaron: then it makes more sense to me that we implement it
<heycam> ... because in theory this should be implemented for blocks too
<heycam> ... as I've mentioned before, I'm worried we'll be unable to implement this for block
<heycam> heycam: is Chrome implementing block alignment as part of your rewrite?
<heycam> iank_: not currently. but the new arch does make it easier to implement
<heycam> astearns: can you get into this situation with abs positioning as well?
<heycam> iank_: I don't think so
<heycam> astearns: given this was not well specified before, can you open bugs on impls to match the current text?
<heycam> TabAtkins: sure
<heycam> rego: so it applies in grid too?
<heycam> TabAtkins: in all places that use this text, so flexbox, grid, and theoretically block
<heycam> RESOLVED: Accept the text in current ED and open bugs on browsers to implement.
<heycam> cbiesinger: can we add WPT tests?
<heycam> iank_: I already have
<RossenF2F> tantek_, probably because folks go in/out of mic proximity