Don't use flex container's `align/justify-content` to influence position of abspos children
Categories
(Core :: Layout: Flexbox, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug)
Details
See https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-745549275
Right now, we "pass" this test and neighboring tests:
https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/align3/flex-abspos-staticpos-align-content-001.html
https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/align3/flex-abspos-staticpos-justify-content-001.html
But based on my notes in my above-linked github comment, I think the spec changed to say these properties don't impact the abspos child's static position, and we need to update our implementation accordingly.
|
Reporter | |
Comment 1•3 years ago
|
||
Relatedly (also mentioned in my github comment linked above): I think we do need to honor justify-self on abspos flex children, and we don't honor that property in that context right now, I'm pretty sure.
(We do honor it for abspos grid children, so this would just be removing a difference between those two.)
|
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 2•3 years ago
|
||
Can you provide a Grid testcase that demonstrates the issue for Grid just so I can understand what this bug is about?
justify-/align-content affects the position of the grid areas, which clearly affects the static position for grid-aligned abs.pos. items...
|
|
Reporter | |
Comment 3•3 years ago
•
|
||
Sorry, I misremembered how this works for grid -- this is indeed a flex-specific thing, I think. No change needed for grid. --> Editing description and comment 0.
(In particular, the bit that I was forgetting was: align-content and justify-content don't directly influence the position of grid items or a grid's abspos descendants; they only set the position of the grid areas, which then serve as the containing blocks for those items/descendants. In contrast: as of bug 1269046, a flex container's align/justify-content properties were supposed to directly influence the alignment of abspos flex children (e.g. centering or end-aligning them within the flex container itself), and apparently the spec has changed so that now they do not.)
|
|
||
Comment 4•3 years ago
|
||
OK, thanks for clarifying. I'm happy there are no changes for Grid. :-)
I'm still a bit puzzled why they are making this change. Take block/table-cell layout for example, where the spec says:
https://drafts.csswg.org/css-align-3/#distribution-block
Alignment Subject(s): The entire contents of the block, as a unit.
That writing seems to imply that the static position SHOULD change with that alignment. It certainly will be a lot harder to implement if we're supposed to move around lines without touching placeholder positions. I suspect the resulting layout will be rather confusing to authors and probably not the layout they want in most cases.
Consider the following table-cell example, which actually implements "The entire contents, as a unit" alignment, although not through align-content yet:
<!DOCTYPE HTML>
<style>
td { position: relative; height: 200px; }
div { position: absolute; }
</style>
<table><td align=center><div>hello</div></td></table>
Does this spec change mean that "hello" should not be centered in this case?
(assuming that we supported and used align-/justify-content:center instead)
|
|
||
Comment 5•3 years ago
|
||
... and if this spec change is specifically ONLY for flex layout: what is the justification for making flex layout behave differently from other kinds of layout in this regard?
|
|
||
Comment 6•3 years ago
|
||
I've read the spec issue now and the resolution seems reasonable. As I understand it, the spec change is that the sizing of the abs.pos. should take the static position into account and that the static position should be influenced by the alignment properties. So this bug's summary doesn't seem to describe the resolution accurately (or I'm still misunderstanding it).
So for example http://wpt.live/css/css-position/position-absolute-center-001.html
The "inner-flex" box is 40px wide and has margin:10px.
It has justify-content: center so the static position for the abs.pos. is at the content-box center (20px), and that position is thus 30px off from the left edge of the CB. The spec now says that the width is double that (60px) which is what Chrome has.
|
|
||
Comment 7•3 years ago
•
|
||
The "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." thing seems a bit weird to me though.
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-513028325
Why not simply use the center position and make the size the distance from there to the relevant CB edge (times two)?
|
|
Reporter | |
Comment 8•3 years ago
•
|
||
I need to spend some time paging in all the changes & spec text here, but my initial assumption was that it's confusing to have an abspos flex child with "align-self:center" inside of a flex container with "align-content: end" for example (or vice versa). abspos elements are positioned independently of one another, so there's no great way for the *-content properties to apply usefully to them in a way that the *-self properties can't already handle.
(The *-content properties are about "how do you align this collection of things cooperatively in this space", whereas the *-self properties are about aligning an individual thing in some space. Normal flex layout has both sorts of aligment in the cross axis simultaneously -- aligning lines and items-within-those-lines, which is why it has both align-content and align-self both operating in that axis. But for abspos flex children, there's only one thing being aligned at a time, within the flex container.)
The behavior-difference that I'm focusing on here is the testcases in comment 0 (direct link to test: https://wpt.live/css/vendor-imports/mozilla/mozilla-central-reftests/align3/flex-abspos-staticpos-align-content-001.html ) Right now chrome positions all of the teal boxes the same, whereas Firefox does some bespoke alignment. Firefox used to be correct on this, but I think the spec change means we're not.
|
|
Reporter | |
Comment 9•3 years ago
•
|
||
(In reply to Daniel Holbert [:dholbert] from comment #0)
https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/align3/flex-abspos-staticpos-align-content-001.html
https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/align3/flex-abspos-staticpos-justify-content-001.htmlBut based on my notes in my above-linked github comment, I think the spec changed to say these properties don't impact the abspos child's static position, and we need to update our implementation accordingly.
Hmm -- actually, if Chrome is to be trusted (and I'm not sure it is), then there may be something a bit more subtle here...
I had initially just noticed that Chrome entirely "fails" the first above-linked test (fully ignoring align-content for positioning abspos children in a flex container), but they basically pass the second test -- they honor justify-content when dealing with abspos flex children, except for the fact that they trip over the start and end values per https://bugs.chromium.org/p/chromium/issues/detail?id=1011718
We honor both (with 'align-content' being honored IFF the flex container is multi-line). Our implementation here is grounded in Flexbox section 4.1, https://drafts.csswg.org/css-flexbox/#abspos-items , which says:
The static position of an absolutely-positioned child of a flex container is determined such that the child is positioned as if it were the sole flex item in the flex container, assuming both the child and the flex container were fixed-size boxes of their used size
I had mistakenly thought this spec-text had been removed, but apparently it has not! Taken directly, this spec-text means the flex container's justify-content and align-content value should be honored when determining the static pos of its abspos children (though only if it's a multi-line flex container, in the case of align-content.) But Chrome doesn't seem to do that, at least for align-content; and I can't find any spec text that directly states what the effect of justify-content is supposed to be on a flex container's abspos children. https://drafts.csswg.org/css-align-3/#distribution-flex would the most authoritative section, and that spec-text just talks about regular flex items, and doesn't mention abspos children static-position at all (whereas the section on the *-self properties has a whole section about effects on abspos elements).
fantasai, I've managed to confuse myself about what the spec is asking for here. Perhaps you can help? :)
The short version of my question is basically: Is flexbox section 4.1 (https://drafts.csswg.org/css-flexbox-1/#abspos-items , quoted above in this bug-comment) still meant to be authoritative in its implications about justify-content and align-content having an impact on the static position of abspos flex children? (And if so, does the css-align spec need to be adjusted to make that impact clearer, perhaps?)
|
||
Comment 10•3 years ago
|
||
Alright, I pulled Tab into looking at this with me. :) We've concluded that the Flexbox 4.1 is internally inconsistent (the normative prose and the note conflict); and Flexbox and Positioning also conflict (the Flexbox note conflicts with the Position normative prose). Filed https://github.com/w3c/csswg-drafts/issues/5843 describing the problem.
Our preference would be to align everything on the CSS Positioned Layout model, since that would give us more consistency in absolute positioning across parent layout models, and would avoid the confusing align-content vs align-self issue you mentioned earlier. But an open question is if that's Web-compatible to ship.
What are your thoughts?
|
|
Reporter | |
Comment 11•3 years ago
|
||
Thanks for taking a look and for filing that issue! I commented over there:
https://github.com/w3c/csswg-drafts/issues/5843#issuecomment-756480046
Let's sort this out over there, and then pick things up here on this bug if/when there's a determination about what the updated requirements are.
|
|
Reporter | |
Updated•3 years ago
|
Description
•