Skip to content
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] Center alignment can be improved #4659

Closed
tabatkins opened this issue Jan 9, 2020 · 7 comments
Closed

[css-align] Center alignment can be improved #4659

tabatkins opened this issue Jan 9, 2020 · 7 comments

Comments

@tabatkins
Copy link
Member

(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 tabatkins added the css-align-3 Current Work label Jan 9, 2020
@tabatkins
Copy link
Member Author

@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
Copy link
Member Author

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
Copy link
Collaborator

fantasai commented Jan 9, 2020

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
Copy link
Member

mrego commented Jan 15, 2020

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
Copy link

bfgeek commented Jan 15, 2020

@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
Copy link
Member

mrego commented Jan 17, 2020

Got it now, it probably makes sense yeah.

@css-meeting-bot
Copy link
Member

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

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 22, 2020
As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
@fantasai fantasai closed this as completed Mar 6, 2020
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 4, 2020
As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 4, 2020
As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Nov 4, 2020
As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2012957
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#823860}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 4, 2020
As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2012957
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#823860}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 4, 2020
As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2012957
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#823860}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 6, 2020
…t tentative., a=testonly

Automatic update from web-platform-tests
[wpt] Make position-absolute-center-* not tentative.

As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2012957
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#823860}

--

wpt-commits: 322c4da99b1d62796d5f4105eb02a745bb35d3f9
wpt-pr: 21341
sidvishnoi pushed a commit to sidvishnoi/gecko-webmonetization that referenced this issue Nov 10, 2020
…t tentative., a=testonly

Automatic update from web-platform-tests
[wpt] Make position-absolute-center-* not tentative.

As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2012957
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#823860}

--

wpt-commits: 322c4da99b1d62796d5f4105eb02a745bb35d3f9
wpt-pr: 21341
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
As per recent CSSWG resolution in:
w3c/csswg-drafts#4659 (comment)

Change-Id: I088059bc4092da07047a89cb19ac1193bb4e8c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2012957
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#823860}
GitOrigin-RevId: 0804d40ec532f86e356780bfc31d296814908e6d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants