-
Notifications
You must be signed in to change notification settings - Fork 657
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-flexbox-1][css-position-3] static position of abspos flex children #5843
Comments
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 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. 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. |
Related issue: #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:
@dholbert said:
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: 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.
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 |
@davidsgrogan Hm, that's a separate question I think. So I guess we have two questions:
So I think those are the cases we need to count? Note that if we don't disconnect |
@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 #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:
Check.
Yep, block axis insets are
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?
|
David and I chatted quickly about this case today. @fantasai am I correct in assuming that your preferred behaviour here is:
Ian |
There's a proposal in w3c/csswg-drafts#5843 to change how the static position is calculated for abspos children of flex containers. This CL is meant to measure how much potential breakage there is. But this CL overcounts the incompatibilities so we'll only get a ceiling on the potential breakage. When the abspos element is the same size as its static position rectangle, the proposed new behavior will match existing behavior no matter the inset or alignment properties. But because Blink never actually stores the static position rectangle, we can't compare it against the abspos size. So even if the sizes match, we don't know, so we just pretend they don't match, which causes overestimating. Note also that this CL checks what I think are the right conditions, which slightly differ from fantasai's, as documented in w3c/csswg-drafts#5843 (comment) Change-Id: Ifc2fc750dd81871adb77eb8044d94e43482a6df0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3652587 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: David Grogan <dgrogan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1007226}
The graph for the first issue from #5843 (comment) is at https://chromestatus.com/metrics/feature/timeline/popularity/4237. It overcounts because we don't have the machinery to check this condition:
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 #5843 (comment), namely only checking the cross axis, not either axis. For the second issue in #5843 (comment) (disconnecting I didn't add a UseCounter because I don't really understand it. I don't think my example that prompted it (#5843 (comment)) 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 #5843 (comment)
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 No engine currently implements |
After sitting with this for awhile it looks like the issue with I filed #7596 to discuss resolving the inconsistency between browser implementations and the spec for |
…on rectangle, matching Grid. #5843 Also move the historical note to CSS Positioned Layout.
@bfgeek The ideal behavior would be to ignore (We might not be able to make that happen for Flexbox due to compat.) |
There's a proposal in w3c/csswg-drafts#5843 to change how the static position is calculated for abspos children of flex containers. This CL is meant to measure how much potential breakage there is. But this CL overcounts the incompatibilities so we'll only get a ceiling on the potential breakage. When the abspos element is the same size as its static position rectangle, the proposed new behavior will match existing behavior no matter the inset or alignment properties. But because Blink never actually stores the static position rectangle, we can't compare it against the abspos size. So even if the sizes match, we don't know, so we just pretend they don't match, which causes overestimating. Note also that this CL checks what I think are the right conditions, which slightly differ from fantasai's, as documented in w3c/csswg-drafts#5843 (comment) Change-Id: Ifc2fc750dd81871adb77eb8044d94e43482a6df0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3652587 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: David Grogan <dgrogan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1007226} NOKEYCHECK=True GitOrigin-RevId: 77e37a5f7cb0817f96c8be42fd3ec5518325d052
This was added for: w3c/csswg-drafts#5843 The graphs are at https://chromestatus.com/metrics/feature/timeline/popularity/4237 https://chromestatus.com/metrics/feature/timeline/popularity/4330 10-20% of page loads so not web compatible. Or at least, the overcounting version of this data collection is very insufficient. Change-Id: I9e7f3aa40513cc05a7ffb44e778f2418ff7e98c5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5871801 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: David Grogan <dgrogan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1356875}
@dholbert pointed out in #1432 (comment) #1432 (comment) 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.
The text was updated successfully, but these errors were encountered: