Open fantasai opened 3 years ago
Our preferred resolution is just to say that Position is correct, and Flexbox was written while we were still figuring things out. We suspect the compat impact of making the changes is minimal, especially since cross-browser behavior seems all over place.
Mm, actually we have a fair amount of interop here. Test results for a statically-positioned abspos child of a flex container:
Note that these behaviors only apply to abspos that are statically-positioned.
Yeah, so the compat situation here (per fantasai's "test results" comment) seems to be that Firefox, Chromium, WebKit, and pre-Chromium Edge all directly implement the Flexbox normative prose (determining the static position as if the abspos thing were the flex container's sole flex item). The only deviation from that is that Chromium, WebKit & pre-Chromium Edge neglect to honor align-content
when determining that position (which per the prose, they should honor iff the flex container is multi-line).
So browsers are mostly consistent on this right now, and have been for at least 3-4 years, which makes changes feel pretty risky from a webcompat perspective.
OK, so proposal: define the static position rectangle of a flex child as:
The first option is consistent with Firefox and the Flexbox spec. The second option is consistent with Chrome and WebKit. The third option is consistent with Chrome and WebKit in the case of row flex containers, but differs in column flex containers in whether align-self or justify-self controls the alignment. However, it means align/justify-self axis mapping would be consistent across all abspos, instead of making a special exception for statically-positioned flex child abspos.
I think if we can do the third option, in the long run (once alignment is implemented for all abspos), it will be better for authors. But we need to consider the compat impact, and would need data for that.
CC @bfgeek @cbiesinger
Related issue: https://github.com/w3c/csswg-drafts/issues/5061
So the question we need an answer to is, would swapping the axes of align-self vs justify-self on an abspos child of a column flex container (i.e. making align/justify match the block/inline split of other abspos, rather than the cross/main of other flex items) break content.
Maybe @davidsgrogan can help with adding a use counter for align-self/justify-self on abspos items in a column flexbox? I guess ideally limiting to items which don't have the corresponding left/top/right/bottom property specified...
I'm interested in this issue because it's a large chunk of failures in https://wpt.fyi/compat2021?feature=css-flexbox and am trying to understand, with the help of @svillar. I'm wondering about these two comments:
@tabatkins said:
cross-browser behavior seems all over place
@dholbert said:
browsers are mostly consistent on this right now, and have been for at least 3-4 years
Getting clarity on this would be great, and seems like it's what should determine the outcome here. If there is already a high degree of interop here, then unless the behavior creates problems for web developers, just sticking with it seems best. But there have been cases in the past when moving away from interop has been the only way to get to a sensible state, so it's not a hard rule. What should happen here?
OK, so interpreting that, there's not interop currently, Firefox has one behavior and Chrome+Safari have a largely matching but different behavior. This matches the test results here: https://wpt.fyi/results/css/css-flexbox/abspos?run_id=5121058602483712&run_id=5638952738357248&run_id=5721849096830976
Since someone will have to change to align, understanding the compat risk indeed sounds important. @bfgeek @cbiesinger do you know if there are use counters for this already?
@foolip, apologies, I agreed to add use counters in another thread and didn't update here.
No worries, I'm just stalking this thread and don't really understand the background and context here. If use counters are being added, it seems like there's a clear next step at least: see if they're <0.01% or so and if we can figure out what kind of content triggers it.
Question about proposed new behavior for which I'm gathering compat data.
align-items
when determining static position of abspos flex childrenalign-items
because the abspos children don't participate in this box's formatting context. (Right?)Which behavior is being proposed here? E.g. These are rendered the same today. Are they rendered the same in this proposal?
<div class=column-flexbox>
<div class=abspos-flex-child style="align-self: center;"></div>
</div>
<div class=column-flexbox style="align-items: center">
<div class=abspos-flex-child></div>
</div>
Both FF and Chrome honor align-items
today as can be seen in bottom flex box at the fiddle above.
@davidsgrogan Hm, that's a separate question I think.
So I guess we have two questions:
For an abspos child of a flex container, would causing align-self
and justify-self
to swap axes (so they match the block/inline axis, like for abspos anywhere else) cause any breaking changes? This requires:
align-self
and justify-self
map to different values in an absolute sense.auto
(and is therefore statically positioned).For an abspos child of any flex container, would disconnecting align-self
from the parent’s align-items
cause any breaking changes? This requires:
align-self
value is auto
.align-items
value is distinguishable from normal
.So I think those are the cases we need to count?
Note that if we don't disconnect align-items
from abspos children, then having align-self
take effect on non-statically-positioned abspos items (as specced in css-align-3) would be more likely to be a breaking change, because it would cause all of those absposes to start responding to the align-items
value of their flex container parents.
@davidsgrogan Is it possible to get counters looking at the above two sets of conditions?
Yes. I have a local WIP patch. It is not as far along as https://github.com/w3c/csswg-drafts/issues/3052 though.
Just update. I haven't worked on this since August but still intend to finish.
@fantasai, question about this case:
<div style="display: flex; flex-flow: column; justify-content: end; width: 100px; height: 100px;">
<div style="position: absolute; justify-self: end; align-self: start; inset-inline: 5px; width: 50px; height: 50px; "></div>
</div>
According to the first set of conditions (the "swap axis" conditions), this counts as a change in behavior, but I don't think this case would actually change under the proposal.
Applying the "swap axis" conditions to this case:
- The flex container in question is a column flex container.
Check.
- The
align-self
andjustify-self
map to different values in an absolute sense.
start
and end
are different. Check.
- The abspos child has both insets in an axis set to
auto
(and is therefore statically positioned).
Yep, block axis insets are auto
. Check.
- The static positioning rectangle is not equal in size to the abspos item’s margin box in that axis (thus the alignment properties can have an effect in this axis).
50x50 and 100x100 are different. Check.
I think check 3 and check 4 need to be scoped to the cross axis, not an axis. Because the proposal only changes behavior for cross-axis positioning, I think, because this part of the proposal matches what engines already do today, right?
In the main axis, the start and end margin edges of the child if it were the sole flex item in the container. [this will lock us to the position defined by justify-content on the flex container]
David and I chatted quickly about this case today. @fantasai am I correct in assuming that your preferred behaviour here is:
align-self
/ justify-self
apply as described in css-align-3).align-content
and justify-content
is it to:
align-content
/ justify-content
for abspos (as the static-position rect can't "shift" for a flexbox).justify-conent
similar to how flexbox is doing it today, but applied like align-self
/justify-self
in css-align-3? (ignoring align-content
).Ian
The graph for the first issue from https://github.com/w3c/csswg-drafts/issues/5843#issuecomment-880999145 is at
https://chromestatus.com/metrics/feature/timeline/popularity/4237.
It overcounts because we don't have the machinery to check this condition:
The static positioning rectangle is not equal in size to the abspos item’s margin box in that axis (thus the alignment properties can have an effect in this axis).
So, even if the rectangle and margin box are equal, we count it as a behavior change.
That graph also implements the slightly different set of conditions from https://github.com/w3c/csswg-drafts/issues/5843#issuecomment-1120333927, namely only checking the cross axis, not either axis.
For the second issue in https://github.com/w3c/csswg-drafts/issues/5843#issuecomment-880999145 (disconnecting align-self
):
I didn't add a UseCounter because I don't really understand it. I don't think my example that prompted it (https://github.com/w3c/csswg-drafts/issues/5843#issuecomment-876794501) is a good one. If you give an example that demonstrates the difference between current behavior and proposed behavior, and we still want a UseCounter for it, I can add one later.
Also, I'm confused by this, from the bottom of https://github.com/w3c/csswg-drafts/issues/5843#issuecomment-880999145
[not disconnecting] would cause all of those absposes to start responding to the align-items value of their flex container parents.
Absposes currently respond to the align-items value of their flex container parents, so I don't get what you mean by "start".
It would be great if this could be discussed at the next meeting. The issue @davidsgrogan linked (and this example in particular) is an instance of where the flexbox spec's requirements for align-content
, justify-content
, align-self
, and align-items
can cause surprising results.
No engine currently implements align-content: stretch
or align-content: normal
as written in css-flexbox so a resolution to the inconsistencies between the flexbox and positioning modules could help with browser interop as well.
After sitting with this for awhile it looks like the issue with align-content
isn't due to disagreement between [css-flexbox-1] and [css-position-3] since position defers to flexbox for this case: https://drafts.csswg.org/css-align-3/#distribution-flex
I filed #7596 to discuss resolving the inconsistency between browser implementations and the spec for align-content
.
@bfgeek The ideal behavior would be to ignore align-content
and justify-content
, yes. Just like in Grid. That would allow the align-self
and justify-self
to consistently control alignment on absolutely-positioned descendants attached to the Flex/Grid container, and to allow the -content properties to focus on managing in-flow content.
(We might not be able to make that happen for Flexbox due to compat.)
@dholbert pointed out in https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-745549275 https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-746947500 and https://bugzilla.mozilla.org/show_bug.cgi?id=1682641#c9 that the newer CSS Positioned Layout model for handling the alignment properties and the flexbox spec conflict on a few points.
First, overall:
A few places where this matters that @dholbert pointed out:
align-self
property will apply in the block axis, not the main axis. But per css-flexbox, it will affect the static position in the main axis.justify-self
property will affect the static position in the inline axis. Per css-flexbox, it can have no effect.justify-content
andalign-content
on the container have no effect on the child's static position. But per css-flexbox, they do.We need to resolve these conflicts somehow.