- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Apr 2018 10:35:21 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Complex float shapes and bfc sizing`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Complex float shapes and bfc sizing<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2452<br> <dael> fremy: [whiteboards]<br> <dael> fremy: Issue is pretty simple<br> <dael> fremy: When you have a float and another float later that has a different shape constraint. We try and size the BFC with the remaining space in the block. If your BFC is taller then the point where size constraint changes then you have to do something.<br> <dael> fremy: In FF every time this happens a new layout is drawn and we try to resize the BFC. It's repeated as many times and needed. It's an arbitrary number of relayouts.<br> <dael> fremy: Chrome looks like some weird behavior where they tried to do it but it broke websites.<br> <dael> fremy: We'd like to find something int he middle<br> <dael> Rossen: We'll layout in the first available space and then slide the other block down until we find space. We're optimizing for not relayout so we avoid overlap<br> <dael> astearns: But you're not using the width of the space.<br> <dael> Rossen: We are. The BFC might become wider and shorter so you don't intersect. When I wrote this in like IE9 you do an intersection with all yoru geometry until you fit the space in your initial BFC and you use that.<br> <dael> iank_: Did you change recently?<br> <dael> Rossen: Maybe but not so much<br> <dael> fremy: We do first layout and move the box at the first place you fit.<br> <dael> Rossen: We may not do relayout.<br> <dael> dbaron: One problem with the description. While making something wider generally makes it shorter, sometimes it makes it taller. Like when you have an overflow:hidden and the image has a fixed width if you make it wider the image get taller.<br> <dael> dbaron: You can't assume that it's going to not overlap.<br> <dael> dbaron: Other thing is these overlap cases happen on real websites, esp wikipeia. Browsers that get this wrong have overlapping content in wikipedia.<br> <dael> dbaron: FF in wikipedia cases have like 3 layouts.<br> <dael> iank_: We looked into this. We think our current impl is a little funky. One thing we can do is you look for next available area that is unbounded and doesn't have a float blocking it off at the bottom.<br> <dael> Rossen: You can have a zig zag of floats. If you want to start filling it with a zig zag you'd push the first BFC down in this case.<br> <dael> iank_: It will skip the zig zag. That's the best 2 pass.<br> <dael> fremy: 2 pass option, first we try and use the size. If you overflow with another float you can try to get the smallest distance that you have in the future and try to layout in that space. If that's more then the minimum space you do the usual.<br> <dael> Rossen: What do you mean it'll work in 2 passes?<br> <dael> fremy: If it doesn't work we do edge behavior, but if it does you find the smallest space in the future. You simplify the geometry and the remaining space is what you try to use.<br> <dael> Rossen: Furthest left and furthest right can be disjointed.<br> <dael> fremy: To get 2 passes. [missed]<br> <iank_> Here is a testcase I created a while ago... https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5370<br> <dael> florian: So furthest left and right, not shortest distance.<br> <dael> dbaron: There's one assumption about gecko you made that I think is wrong. I think you assumed we did a layout...let me check...<br> <dael> dbaron: I think we're using intrinisic min-content width and not doing layout.<br> <dael> dbaron: We're doing a layout to determine the height.<br> <dael> Rossen: That's the one we're talking about. THe widths are created by the geometry.<br> <dael> dbaron: I need to read it.<br> <dael> iank_: One thing to point out is when you introduce margin collapsing if the BFC 'smargin effects position of floats.<br> <dael> Rossen: If BFC psoitions after the floats it will have to be in content order. Only thing that could be effected is BFC position<br> <dael> iank_: Margins collapsing through in an empty div.<br> <dael> Rossen: But they're already committed.<br> <dael> iank_: Not until you know the final margins.<br> <dael> iank_: You can have a margin that's further down in the doc that effects where the floats re positioned.<br> <dael> Rossen: You'll have to show me the test case.<br> <dael> ??: top margin will collapse through?<br> <astearns> s/??/Rune<br> <dael> iank_: Yes.<br> <dael> Rossen: dbaron did you get this into your head?<br> <dael> dbaron: Kinda. There are a set of positions you can reject without layout.<br> <dael> Rossen: What does 2.1 spec suggest?<br> <dael> astearns: From my recollection when defining shapes, FF has the right behavior where you slide things until it fits.<br> <dael> Rossen: What do you mean by slide? In fremy picture, would you consiter sliding?<br> <dael> astearns: I recall line layout, not BFC.<br> <dael> Rossen: line layout is regid.<br> <dael> dbaron: Line layout has the same problem because the line can get longer.<br> <dael> astearns: And trying them at a lower position can change the width.<br> <dael> Rossen: [draws]<br> <dael> Rossen: Assuming this geometry is what you have to play with (large multi tiered box) what do you mean by sliding?<br> <dael> Rossen: Let's assume everything above is taken. First place you can position is here Then you arrive and get to some kind of layout. Is sliding on he x axis? one of the geometries?<br> <dael> dbaron: For both line layout and BFC you have 2 nested loops. If you fail to fit....the outer loop is over your y position and the inner is over your reduction in width.<br> <dael> dbaron: If you try and place here and fail because it intersects below you narrow your width to account for the intersection and try again. You go until you fit or you fail but there's no more floats.<br> <dael> dbaron: That's the inner loop. Outer loop is we failed to find a width for this vertical position so then we move down to the next vertical position with more room.<br> <dael> dbaron: In the simple case what we impl right now is look for next position where something changes.<br> <dael> dbaron: Traditional floats it's not that bad, in shappes we should loop<br> <dael> iank_: On shapes we switched shape sizes and BFC so shape has no effect on BFC.<br> <dael> dbaron: I hink you can exclude a decent amount of things.<br> <dael> astearns: Changing what you're doing depending on float or shape I don't think that makes that much sense. Everything you can do with hspaes you can do with floats.<br> <dael> iank_: We have use counters saying it's not used so we switched it off.<br> <fantasai> s/floats/sufficient number of floats/<br> <dael> astearns: I'm not that concerned with BFCs but everything we're discussing as a problem for BFCs is also a problem for placing first line of non-BFC content next to lfloats.<br> <dael> iank_: SLightly different.<br> <dael> Rossen: In general what you desc makes sense. I hope there's a spec where we can define this. I failed to find anything when I impl.<br> <dael> astearns: Section 9.5.1<br> <dael> dbaron: 2.1 defines it for lines but not well for BFC is my memory.<br> <dael> dbaron: All float rules in 2.1 are in terms on constraints and this is a case where constraints is a bad way of defining it.<br> <dael> fremy: This is potentially a lot of layout.<br> <dael> iank_: In our new impl of block layout we went with FF behavior going through each oppotuniry.<br> <dael> Rossen: From user POV tat's the better behavior.<br> <dael> iank_: I can describe the 2 pass method.<br> <dael> iank_: The 2 pass one is layout and the based on I think min-content you lay out in one of the areas.<br> <dael> fremy: I proposed you first try the first position. Then you try the furthest right space. If it's bigger then the min-width you put the element there. That's what Edge is doing. I'm faily confident that'll work almost all the time and then you don't have to layout again and again. As an author you don't expect this to be super expensive, but it can be.<br> <rego> this non-BFC example has overlapping issues on Blink/WebKit http://jsbin.com/yebelixowu/1/edit?html,css,output<br> <dael> florian: If I understand dbaron in the case without minimum the extra part you compress. But if you have the minimum you have to do a re-layout.<br> <dael> dbaron: Most expensive case is [whiteboards] a table and you're dealing with a shape that has a really rough uneven edge.<br> <dael> dbaron: So you keep having to relayout.<br> <dael> iank_: This is why we switched this off for shapes.<br> <dael> fremy: We only do this a few ties and then give up and overflow the floats.<br> <dael> fremy: What this would do is it would try to lay it out and if it doesn't work it would put the table under the shape.<br> <dael> astearns: I'm not sure the example of the narrowest place works for this example.<br> <dael> dbaron: Depends on what the shape is.<br> <dael> fremy: If the table fits it fits. If it's bigger it goes undermeath.<br> <dael> myIes: I think the point is it's valid, but not good.<br> <dael> astearns: I see the appeal from an impl side, but as an author I can't imagine wanting...if an author wants the content as far up in the layout as possible so FF and half of Chrome is what I expect an author would want.<br> <dael> astearns: If we have to have a strategy to avoid re-layouts, giving up and going past the floar may be better.<br> <dael> fremy: Chrome would like to remove this thing.<br> <dael> iank_: We've removed shapes. WE added counters to shapes and barely saw usage. I believe shapes now only effect line-boxes.<br> <dael> iank_: As people add lots of lfoats, sure. Shapes is easy to go into every max-length.<br> <dael> dbaron: I think saying shape-outside doesn't effect BFC is a reasonable comprimise.<br> <dael> astearns: We deferred to 2.1 in the spec.<br> <dael> fremy: [missed]<br> <dael> dbaron: I think wikipedia looks better with the algo.<br> <dael> fremy: In most cases you do it in 3 which gets you same result.<br> <dael> dbaron: It's reasonably common that the narrowest thing will be something narrow.<br> <dael> astearns: Because we counter with shapes and BFCs is small, a different rule for BFC is fine. But I'd hate that to be preceident for line layout.<br> <dael> iank_: That's easier because when you do the first pass you know the height.<br> <dael> astearns: I don't mind as long as it doesn't apply to line layout.<br> <dael> florian: Are you sure problem isn't for lines<br> <dael> dbaron: You don't change height of the line depending on it getting narrower. If you shrink the line it might shrink, but it might not increase in height. If you shorten the line and it gets shorter in height, but it fits, you leave it.<br> <dael> iank_: Always works in 2 passes.<br> <dael> Rossen: And BFC the norrow you make it the longer it gets usually.<br> <dael> dbaron: You can guar the shortening look is 2, the moving down can be more loops.<br> <dael> fremy: 2 proposal. 1 to say BFC....<br> <dael> Rossen: 1) Do all possible layouts which will optimize for the area.<br> <dael> myles: 2) layout to widest. If it doesn't fix calculate some numbers and if it doesn't fix push it.<br> <dael> myles: 3) is always push it.<br> <dael> Rossen: We try and find space for the layout and then push it.<br> <dael> fremy: Reason we're here is we've found 3 is not good on wikipedia.<br> <dael> myles: 1 is what user wants. astearns pointed out option 3 may be better then option 2 for user.<br> <dael> fremy: [missed]<br> <dael> astearns: Option 1 will often find a > min place to put the BFC.<br> <dael> fremy: Not as likely.<br> <dael> dbaron: Depends on the floats.<br> <dael> dbaron: If your floats are like this (smallest on top right) then you'll be find on the top.<br> <dael> iank_: [whiteboards]<br> <dael> Rossen: Can I make a proposal? I'm not sure we'll be able to resolve without wasting more paper. Holding the whole group on this prob. not very helpful. Let's take this over lunch with the people interested.<br> <dael> Rossen: So what we believe is best for user and impl and we'll come back after the break.<br> <fantasai> Iank drew two stepped sets of floats, one of decreasing widths on the left, on eof increasing widths on the right, leaving a diagonal channel<br> <dael> dbaron: I think one resolution that solves part of the problem is the interaction with shapes and BFC. Prop: BFC flow around floats don't care about shape-outside.<br> <dael> fremy: If you do shape-outside and you do a float BFC is wrong. If you do shape outside the entire element floats.<br> <dael> florian: For FC it's rare enough it's okay.<br> <dael> Rossen: Shapes with BFC is probably not common. Shapes with text is how feature was intended.<br> <dael> myles: why do we want this proposal<br> <dael> iank_: Impl complex.<br> <dael> dbaron: Gets rid of worst cases.<br> <dael> myles: You just look at mins and maxes<br> <dael> Rossen: Whatever you have with shape you can make with floats.<br> <dael> dbaron: Okay, I take back that we might be able to resolve.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2452#issuecomment-380053443 using your GitHub account
Received on Tuesday, 10 April 2018 10:35:27 UTC