- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Apr 2018 12:03:33 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Complex float shapes and bfc sizing`, and agreed to the following resolutions: * `RESOLVED: The working group preference is to specify BFC float avoidance behavior to match the guidelines of what is spec in 2.1 for inline layout float avoidance behavior` * `RESOLVED: Start a CSS 3 Floats Module with dbaron and fremy as co-editors` <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> Rossen: This is the picture we were trying to illustrate on the white board. It's intended to illustrate the 3 proposals.<br> <dael> action Rossen send the image of https://github.com/w3c/csswg-drafts/issues/2452 discussion to archives<br> <trackbot> Created ACTION-872 - Send the image of https://github.com/w3c/csswg-drafts/issues/2452 discussion to archives [on Rossen Atanassov - due 2018-04-17].<br> <dael> fremy: Proposal #3 is when you have an image that overflows you just push it down, but that was also leaving a lot of empty space. Edge is doing that right now.<br> <dael> Rossen: We do one layout. We're assuming inline is in top left.<br> <dael> astearns: BFC tried for full width and intersected with float.<br> <dael> Rossen: Right. If we don't fit because we intersect we try and fit and end up at the bottom (behavior #3)<br> <dael> florian: Width is full width of containing block?<br> <dael> Rossen: Might not. It doesn't fit.<br> <dael> fantasai: That's super weird.<br> <dael> Rossen: And super performant.<br> <dael> astearns: Edge is getting bugs on clearing and leaving the empty space above.<br> <fantasai> Rossen was explaining that once they've cleared past the floats into a larger-width area, they don't lay out into that larger area but keep the width of the initial reflow<br> <fantasai> This is what I thought was super weird<br> <dael> Rossen: Say you have a div and a tiny 0 width float and then another smaller float. In this case there's a 0 width which we layout the BFC next to the 0 width. BUt it intesects with the smaller float. Then we slide the BFC down. Say it doesn't fit and then it's before the small float.<br> <dael> Rossen: you can argue we can fix our bug with behavior #2 which has different drawbacks.<br> <dael> fremy: Proposal #2 is if it doesn't fit you try one more layout. You try to find first place you can fit the min content of the BFC you're trying to place. If you can fix the min-content you put it there. Downside is you may end up in a situation where it goes down if the min-width is too small. You try to find somewhere you can fit the min width. It doesn't require any layout. It's a guar valid. Drawback is it could be min width is very small so yo uget very tall.<br> <dael> florian: In this logic if there is several places you can fit do you try all?<br> <fantasai> s/fix the min-content/fit the min-content and there are no floats limiting the height below it/<br> <dael> iank_: The first one. In this case there's three areas. You start at the first and if it fits you put it there.<br> <dael> fremy: If it doesn't you try the second and then the third.<br> <dael> iank_: It's a 2 pass layout and you're trying all areas.<br> <dael> astearns: It fixes the floated UI issue.<br> <dael> fremy: Option 1 is Firefox. It's literally trying all possibilities.<br> <dael> fantasai: Nobody gets the rainbow where it is?<br> <dael> Rossen: Firefox is rainbow.<br> <dael> iank_: I posted a link at 1:22 pm of a test case for this.<br> <dael> myles: rainbow is FF, 3 is edge, no one does 2.<br> <dael> iank_: Blink and webkit is undefined.<br> <dael> fremy: There's one thing I don't like is that.<br> <dael> Rossen: People use offset flows. [missed] it's the only way to offset floats veritically.<br> <dael> fremy: No gap here (position the float, the then BFC) means that someone really wanted that space.<br> <dael> astearns: So we have 3 which goes below the floats. 2 which makes and attempt based on heuristics and 1 which does the best but is expensive.<br> <dael> fremy: Also will Chrome disable this for shapes.<br> <dael> astearns: Rossen said there was a conclusion.<br> <dael> fremy: [missed]<br> <dael> group decision: no conclusion<br> <dael> fremy: If people won't agree on #2...I thinkw e should resolve on 2.<br> <dael> Rossen: 2 is improvement for us and Chrome and reduced experience in FF.<br> <dael> iank_: The test case I dumped in IRC we do 2 in.<br> <gsnedders> what test case?<br> <dael> astearns: Would anyone objec to spec the second option?<br> <dael> dbaron: Who does it now?<br> <gsnedders> 12:22 < iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5879<br> <dael> many: no one<br> <dael> dbaron: I would object to spec something no one does.<br> <dael> fremy: We can't spec what Chrome is doing. Firefox is option 1. That's better then our version.<br> <dael> astearns: Sounds like we don't agree.<br> <dael> iank_: WE can see how expensive 1 is.<br> <dael> Rossen: We can resolve on 1, ask whomeever impl it to spec it. If this is performance we can ask to get some data back. In the meantime other impl...we'll do something to fix. For normative behavior it's hard to argue #1 isn't the best. It's up to us to figure out easy engineering tricks to optimize as much as possible.<br> <dael> Rossen: So is there objections to #1?<br> <dael> fantasai: Sounds better.<br> <dael> astearns: Objections to spec #1 for BFCs?<br> <dael> fremy: No special about shapes?<br> <dael> Rossen: No, nothing special about shapes.<br> <dael> astearns: If we spec we'd need a floats module.<br> <dael> Rossen: Let's get a resolution about the behavior we want.<br> <rego> https://github.com/w3c/csswg-drafts/issues/2452<br> <dael> astearns: Prop: The working group preference is to specify BFC float avoidance behavior to match what is spec in 2.1 for inline layout float avoidance behavior<br> <dael> Rossen: ish.<br> <dael> astearns: To follow those guidelines and spec it well.<br> <dael> astearns: Obj?<br> <dael> RESOLVED: The working group preference is to specify BFC float avoidance behavior to match the guidelines of what is spec in 2.1 for inline layout float avoidance behavior<br> <dael> Rossen: Where does this go?<br> <dael> florian: 2.1?<br> <dael> astearns: I think floats module. 2.1 is vague on inline.<br> <dael> Rossen: In CSS positioning the fork happened for floats and position.<br> <dael> fantasai: I'd rec not in the same module because psoitioning and floats are quite divergent.<br> <dael> Rossen: That's okay. We can take the line out of 2.1 and start a module.<br> <dael> Rossen: A resolution for that?<br> <dael> gsnedders: If we're removing a line from 2.1 we should have a resolution.<br> <dael> astearns: We're not taking out, we're making a module to refine.<br> <dael> astearns: objections to someone creating a css float module at some point?<br> <dael> Rossen: I can create the fork and start it.<br> <dael> dbaron: I can help, but I don't want to be only person<br> <dael> astearns: objections to rossen and dbaron creating a css float module?<br> <dael> smfr: This isn't about float layout, but wrapping behavior. So if shapes trigger same behavior doesn't make sense.<br> <dael> astearns: Shape outside is in relation to floats and exclusions would tie in.<br> <dael> fantasai: I think floats is right place.<br> <dael> dbaron: I think if I'm putting it with something it would be block layout and that doesn't really have a L3 for that.<br> <dael> myles: That's better then proposal. Rather then a new spec we should have someone take up stewardship of the block layout<br> <dael> fantasai: It has more stuff in it.<br> <dael> astearns: Like with any other module the bits and pieces that refer to other specs say it's defined over there.<br> <dael> astearns: Can be floats module, can be wrap. They're pretty synonymous for css so I don't care on the name.<br> <dael> Rossen: Floats is more specific and targeted.<br> <dael> astearns: Prop: Start a CSS 3 Floats Module with dbaron and fremy as co-editors<br> <dael> RESOLVED: Start a CSS 3 Floats Module with dbaron and fremy as co-editors<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-380074237 using your GitHub account
Received on Tuesday, 10 April 2018 12:03:57 UTC