- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Nov 2021 23:43:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-3] Ancestor Layout Loops with Single-Axis Containment`, and agreed to the following: * `RESOLVED: Accept iank_'s proposal to guarantee full layout algorithm is always forward moving` <details><summary>The full IRC log of that discussion</summary> <dael_> Topic: [css-contain-3] Ancestor Layout Loops with Single-Axis Containment<br> <dael_> github: https://github.com/w3c/csswg-drafts/issues/6426<br> <dael_> miriam: It turns out this is hard. We knew that<br> <dael_> miriam: I tried to document 4 known instances where content changing size on 1 axis, generally block, has impact on available size for inline. So if we try and contain inline only get a loop<br> <dael_> miriam: Generally have a pattern where outer ancestor, element contained on inline axis, inside of that contents responding to container query<br> <dael_> miriam: With those three nested bits, a few of the issues are orthogonal writing modes. 2 other cases that are common. Ancestor is overflow scroll ad the contents can trigger scrollbar on ancestor which changes inline space available<br> <dael_> miriam: Another is floats as they get taller or shorter how they stack might change<br> <dael_> miriam: In my first document I wrote out the brute force solutions. They're not ideal for users. iank_'s idea is better<br> <dael_> iank_: I need to study one of these a bit more but they all fall into effectively we layout a child once with given space, read child height, and based on that give it a new available space.<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9775<br> <dael_> iank_: Fundamentally need to make sure we never walk backwards. This is true today<br> <dael_> iank_: I pasted in irc an example ^<br> <dael_> iank_: Orange box and inside it has a child with an a-r. Conisder width first, get height where we can't fix. Then consider second of 50px. All engines walk forwards like that.<br> <dael_> iank_: We don't try and say now that I'm this height maybe i could fit back here after all<br> <dael_> florian: Do you mean this is hte end of hte line principle we don't need the pieces miriam highlighted or that it solves them all?<br> <Rossen_> q?<br> <florian> q+<br> <fantasai> me q-<br> <dael_> iank_: I think we state it and it solves them all. Orthogonal. We layout with one set of contstraints, layout, adjust. We move forward.<br> <fantasai> s/me q-//<br> <Rossen_> ack florian<br> <dael_> florian: I'm a bit concerned this is different than float. We should avoid making css accidently stateful<br> <dael_> florian: Float, ancestors are not effected by float in the same way<br> <dael_> florian: Roughly I feel the way miriam proposed is annoyingly specific but need to do it to avoid vague or stateful<br> <dael_> iank_: I don't think it's stateful. We have a bug on orthogonal, but with that case to compute intrinsic size for the orthogonal child we need to lay it out with some available size.<br> <dael_> iank_: We layout with that size. may effect size of the parent. Now when we do layout pass we give orthogonal child different constraints and it lays out differently<br> <dael_> florian: That sounds true<br> <dael_> iank_: If you can come up with a case you think is stateful happy to access<br> <dael_> iank_: Orthogonal is hard b/c engines have a lot of bugs. miriam example shows a bug<br> <dael_> florian: For scrollbar and padding do you think we can get away without hatchet miriam proposed?<br> <dael_> iank_: I think so. A-r is fine, floats is fine, I think classic scrollbars is fine as long as you add them in a particular way. We'll slowly add scrollbars to get to a state. I think it should be okay<br> <dael_> florian: I thought if you didn't have miriam approach you would get a different result if you start on a 800 px window different result then if you start bigger and sthrink<br> <dael_> iank_: No, shouldn't be an issue. That's a browser issue and should be fixed.<br> <dael_> iank_: If there is an ambig set of steps where we need more specific order we should do that<br> <dael_> iank_: When forming a new context in relation to floats we had a specific order on how people should walk through. Pretty much everything else falls into that<br> <dael_> florian: If we go that way we can have a spec that's less magic but we need to be very precise so it's stable and interop<br> <dael_> iank_: yes<br> <dael_> florian: Can someone implementing list the steps? Undefined would be bad<br> <dael_> iank_: Depends what you mean by define<br> <dael_> iank_: We don't have a spec for block layout but we have resolved how floats behave.<br> <dael_> iank_: I can describe how this works for orthogonal children, I think that's well defined<br> <dael_> florian: My ask would be for the 4 cases miriam highlighted which I think are specific enough, could you either point to the spec language that make them non-problematic or propose sufficient spec text?<br> <dael_> iank_: I can work with miriam on that<br> <dael_> Rossen_: Sounds like we're forming consensus around going forward with reasoning captured in the issue by iank_. Additional exercise to figure out where changes have to land<br> <dael_> Rossen_: Anything else to add here? I see people on this issue chimed in<br> <dael_> florian: Great if we can go there. The things proposed are cludges we thought unavoidable. If they're avoidable, great<br> <dael_> Rossen_: In terms of solution anything else to add here?<br> <dael_> dholbert: I think your example with a-r is a good case for something that behaves like this without needing container queries. Good extension of that<br> <dael_> iank_: I think I can create examples as well with time<br> <dael_> Rossen_: We call them test cases; please add them :)<br> <dael_> Rossen_: Let's resolve on path forward. And it'll be iank_ for you to figure out wehre edits should go<br> <dael_> Rossen_: Prop: Accept iank_'s proposal to guarantee full layout algorithm is always forward moving<br> <dael_> florian: Sort of important to get to this in a timely manner. This discussion has been going on for years in GH. If there is a solution, great, but I'm worried we will force other browsers to reverse engineer crhome or do something else if we don't write it<br> <dael_> chrishtr: resolution to go with iank_ proposal?<br> <dael_> iank_: write it down at least for the examples. Part of the problem is large parts of some algos are undefined. Can spac how things should walk forward<br> <dael_> chrishtr: So parts of algo that intersect need to be written<br> <dael_> iank_: Part of issue is float not well defined. List of side effects. most recent for float layout is in a GH issue but not in spec. Pointing to the various places we've resolved<br> <dael_> iank_: For intrinsic size we have it written<br> <dael_> florian: I don't think iank_ proposal is not self contained enough. It's an approach we need to look into more details.<br> <dael_> Rossen_: yes. We don't have specificals<br> <dael_> florian: We agree to try and solve that way. And we go that way and we come back to resolve on details<br> <dael_> Rossen_: Have proposed path forward. Don't have details about specifics, but approach makes sense. You've made your point and people agree.<br> <dael_> fantasai: We had previously declined to publish fpwd because of this issue. If we get to a point we're okay with the issue we should publish fpwd<br> <dael_> previous proposal: Accept iank_'s proposal to guarantee full layout algorithm is always forward moving<br> <dael_> Rossen_: That's the proposed resolution. Obj?<br> <dael_> RESOLVED: Accept iank_'s proposal to guarantee full layout algorithm is always forward moving<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6426#issuecomment-960298637 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 November 2021 23:43:57 UTC