[LayoutNG] Improve handling of adjoining floats.
A float always needs to be positioned by its block parent, so passing them around to children, parents or siblings really shouldn't be necessary (and it *was* somewhat confusing, since nobody but the direct float parent is allowed to touch them anyway, apart from placing them into temporary exclusion spaces). The main reason for passing them around like that, was for other blocks to determine, based on the list of floats being empty or not, the need for relayout once the BFC offset was resolved. Instead, confine the list of unpositioned floats to the block parent of those floats, and introduce the concept of adjoining float types (none, left, right, both). Adjoining floats occur when the BFC offset is unknown, meaning that their position may be affected by the current layout algorithm. Adjoining float types will now be the thing that's both input to and output from the layout algorithms. Having something other than "none" means that a block's BFC offset is unknown, but that doesn't automatically mean that we have to abort and re-layout if the BFC offset gets resolved. If the "floats BFC offset" is known, for instance, those adjoining floats may be positioned right away. Still we need to know about them (positioned or not), to get clearance correct. We're going to need to treat adjoining floats specially when applying clearance. Will deal with that in a later CL. For now, we just keep track of the adjoining float types, so that the clearance machinery can tell that there are floats there that may not yet be positioned. That used to be taken care of the list of unpositioned floats, but, as previously stated, adjoining floats are special, and we need to know about them, whether they are positioned or not. This is a preparatory CL for that. Each time we add an unpositioned float, we need to update the types of adjoining floats, so that these can be returned from the algorithm if necessary. Whether they end up being positioned right away or not isn't relevant. Adjoining is adjoining. Note that we don't have to #include the header file for unpositioned floats as much as before now, but I'll clean that up in a follow-up CL, because it turned out that there were quite a few translation units that got stuff for free via that header file, instead of explicitly including what they need. Had to rewrite how we deal with floats in HandleNewFormattingContext() and LayoutNewFormattingContext(), since those depended on a list of all preceding unpositioned floats to place them into a temporary exclusion space, to figure out whether to let the child's margin be adjoining with the current margin strut or not. Instead of using a temporary exclusion space, we now position floats via the regular mechanisms, and initially assume that the child's margin is going to be adjoining. This means that we have to abort and roll back if there are preceding unpositioned floats. This is no different from how we lay out regular blocks, though. What *is* different is that if it turns out that the child's margin has to be separated from the strut, we'll have to abort and roll back once *again* (but only once). The algorithms now need to keep track of whether they need to abort if the BFC offset *changes*, rather than if it is *resolved*. We only allow the offset to resolve and optionally change *once* afterwards, though. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng Change-Id: Ie527d659213049f180ebedc764e1d7f4926a5876 Reviewed-on: https://chromium-review.googlesource.com/1030191 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by:Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by:
Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#555314}
Showing
This diff is collapsed.
Please register or sign in to comment