Layout 2020: Move all Fragment code to the `fragment_tree` directory
This is a simple code organization change with no behavior change with the idea of making Layout 2020 easier to understand by new folks to the project. The idea is that we will have a cleaner separation between the different parts of layout ie one directory for the fragment tree and one (currently multiple) directory for the box tree.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they do not change behavior.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
This is a simple code organization change with no behavior change with
the idea of making Layout 2020 easier to understand by new folks to the
project. The idea is that we will have a cleaner separation between the
different parts of layout ie one directory for the fragment tree and one
(currently multiple) directory for the box tree.
Instead of hoisting floated fragments to be siblings of the fragment
created by their containing block formatting context, keep them in
"normal" fragment tree position and adjust their positioning to be
relative to the containing block. This means that float fragments follow
the existing invariants of the fragment tree and properly handle hit
testing, painting order, and relative positioning.
The tradeoff here is more complexity tracking the containing block
offsets from the block formatting context (including handling collapsed
margins), but less complexity dealing with hoisting / shared ownership
in addition to the correctness benefits.
Some tests are failing now because this change revealed some additional
shortcomings with clearing block formatting context content size past
the end of their contained floats. This will be fixed in a followup
change.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This commit puts floats behind the `layout.floats.enabled` pref, because of the
following issues and unimplemented features:
* Inline formatting contexts don't take floats into account, so text doesn't
flow around the floats yet.
* Non-floated block formatting contexts don't take floats into account, so BFCs
can overlap floats.
* Block formatting contexts that contain floats don't expand vertically to
contain all the floats. That is, floats can stick out the bottom of BFCs,
contra spec.
During layout it is often useful, for various specification reasons, to
know if an element is the `<body>` element of an `<html>` element root. There
are a couple places where a brittle heuristic is used to detect `<body>`
elements. This information is going to be even more important to
properly handle `<html>` elements that inherit their overflow property from
their `<body>` children.
Implementing this properly requires updating the DOM wrapper interface.
This check does reach up to the parent of thread-safe nodes, but this is
essentially the same kind of operation that `parent_style()` does, so is
ostensibly safe.
This change should not change any behavior and is just a preparation
step for properly handle `<body>` overflow.
Manage containing blocks and WebRender SpaceAndClip during stacking
context tree constuction using the ContainingBlockInfo data structure.
This will allow us to reuse this data structure whenever we traverse the
fragment tree. In addition, StackingContextBuilder is no longer
necessary at all. This change also fixes some bugs where fixed position
fragments were not placed in the correct spatial node. Unfortunately,
these fixes are difficult to test because of #29659.
context, to place floats in layout 2020.
The containing block for a float is not necessarily the same as the block
formatting context the float is in per CSS 2.1 [1]:
"For other elements, if the element’s position is relative or static, the
containing block is formed by the content edge of the nearest block container
ancestor box."
This shows up in the simplest case:
<html>
<body>
<div style="float: left">Hello</div>
</body>
</html>
In this case, the `<html>` element is the block formatting context with inline
size equal to the width of the window, but the `<body>` element with nonzero
inline margins is the containing block for the float. The float placement must
respect the content box of the `<body>` element (i.e. floats must not overlap
the `<body>` element's margins), not that of the `<html>` element.
Because a single block formatting context may contain floats with different
containing blocks, the left and right "walls" of that containing block become
properties of individual floats at the time of placement, not properties of the
float context itself.
Additionally, this commit generalizes the float placement logic a bit to allow
the placement of arbitrary objects, not just floats. This is intended to
support inline layout and block formatting context placement.
This commit updates the `FloatContext` and associated tests only and doesn't
actually wire the context up to the rest of layout, so floats in pages still
aren't actually laid out.
[1]: https://drafts.csswg.org/css2/#containing-block-details
2020, not yet wired to the rest of layout.
This commit implements an object that handles the 10 rules in CSS 2.1:
https://www.w3.org/TR/CSS2/visuren.html#float-position
The implementation strategy is that of a persistent balanced binary search tree
of float bands. Binary search trees are commonly used for implementing float
positioning; e.g. by WebKit. Persistence enables each object that interacts
with floats to efficiently contain a snapshot of the float list at the time
that object was laid out. That way, incremental layout can invalidate and start
reflow at any point in a containing block.
This commit features extensive use of
[QuickCheck](https://github.com/BurntSushi/quickcheck) to ensure that the rules
of the CSS specification are followed.
Because this is not yet connected to layout, floats will not actually be laid
out in Web pages yet.
Note that unit tests as set up in Servo currently require types that they
access to be public. Therefore, some internal layout 2020 types that were
previously private have been made public. This is somewhat unfortunate.
Part of #25167.
… and converting them to flow-relative geometric values.
These values are almost always used to size and position a fragment within its containing block, so using the mode of the containing block seems more correct.
Note that the `writing-mode` and `direction` properties are disabled in Servo at the moment, so this PR by itself should have no effect: the writing mode of an element is always the same of that of its containing block since they’re both horizontal rtl.
We want to mutate them when lazily computing their content sizes, but they
are behind an Arc for the hoisting infra, so it also needs its own layer
of inner mutability.
We want to compute content sizes on demand rather than eagerly so we will
need to mutate the independent formatting contexts that own the content sizes.
This avoids the use of lookup tables for containing blocks when
constructing the stacking context tree.
This seems to catch some laid-out hoisted fragments that were otherwise
dropped in the previous design. The changes cause one new test to pass
and one to fail. Visual examination of the failing tests reveals that
it's a progression (list markers are appearing when they were previously
not rendered).
Instead of painting hoisted position fragments in the order to which
they are hoisted, paint them in tree order and properly incorporate them
into the stacking context.
We do this by creating a placeholder fragment in the original tree position
of hoisted fragments. The ghost fragment contains an atomic id which
links back to the hoisted fragment in the containing block.
While building the stacking context, we keep track of containing blocks
and their children. When encountering a placeholder fragment we look at
the containing block's hoisted children in order to properly paint the
hoisted fragment.
One notable design modification in this change is that hoisted fragments
no longer need an AnonymousFragment as their parent. Instead they are
now direct children of the fragment that establishes their containing block.
This is a feature that was never properly implemented in the previous
layout system. We still need to preserve their in-tree order in the
display list though.
This method doesn't actually do any layout, but converts this block to a
HoistedAbsolutelyPositionedBox which is hoisted and then laid-out with
its containing block later. This makes the code a little easier to read.
Iits details are now private to the module.
It has a couple methods that take closures to make sure that "before" and "after" steps are done together:
* In an absolutely positioned box, take care of nested abspos (establish a new containing block, etc.)
* For a box that *might* be `position: relative`, optionally take care of the same.
