* Add initial support for sticky positioning for non-legacy layout
Many tests still fail for a variety of reasons. One of the primary ones
is that CSSOM currently does not return correct values for elements
positioned by sticky nodes. This requires changes to WebRender to work
properly.
* Fix an assertion failure in the legacy layout sticky code
Refactor the scrolling and scrollable area calculation on the window
object, to make it better match the specification. This has some mild
changes to behavior, but in general things work the same as they did
before. This is mainly preparation for properly handling viewport
propagation of the `overflow` property but seems to fix a few issues as
well.
There is one new failure in Layout 2020 regarding `position: sticky`,
but this isn't a big deal because there is no support for `position:
sticky` in Layout 2020 yet.
Co-authored-by: Rakhi Sharma <atbrakhi@igalia.com>
This makes the names of flow relative geometry consistent with what is
used in the style crate and removes them from a module. With this change
it's more obvious what makes these types different from the ones in
`euclid`.
When layout was split into two phases, floats were laid out as direct
children of the inline formatting context. This meant that they were
positioned properly, but not properly made children of their inline
ancestors' stacking contexts. This change maintains the proper
positioning of floats, but positions them relatively to their inline
ancestors.
The big change here is that `text-align` needs to be taken into account
before actually laying out LineItems. This has the added benefit of
setting inline layout for the implementation of `text-align: full`. Now
all line items are laid out at the real final position and we can adjust
the `start_corner` property of float `BoxFragments` when their ancestors
are laid out.
In the first phase, we gather LineItems and then when we have enough to
form a line we turn them into Fragments. This will make it possible to
more simply implement `vertical-align` and `text-align: justify` because
we need to measure the different aspects of the candidate line and then
produce a Fragments.
This is a general refactor of the way that inline layout works, so comes
with some progressions. In addition there are some new failures.
New failures:
Some tests are now failing because only the test or reference is getting
proper line height when it wasn't before. These should be fixed in a
followup change that properly calculate line-height in more cases:
- /_mozilla/css/list_style_position_a.html
- /css/CSS2/floats/float-no-content-beside-001.html
- /css/css-content/pseudo-element-inline-box.html
- /css/css-flexbox/flexbox_flex-none-wrappable-content.html
Some tests are now failing because floats are now placed properly, but
are no longer in their inline box stacking contexts. These will be fixed
by a followup change which properly parents them:
- /css/filter-effects/filtered-inline-applies-to-float.html.ini
- /css/css-color/inline-opacity-float-child.html.ini
One test is failing due to floating point precision errors:
- /css/CSS2/floats-clear/floats-141.xht.ini
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Clearance was implemented as a Length, where zero meant no clearance.
However, having a clearance of 0px should be different than having
no clearance, since the former can still prevent margin collapse.
This patch keeps the existing behavior, so it won't be possible to get
a clearance of Some(Length::zero()), but it prepares the terrain for
a follow-up to fix calculate_clearance to return the proper thing.
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.
The specification dictates quite quite idiosyncratic return values when
querying insets of positioned elements via getComputedStyle(). These
depend on whether or not the elements size was overconstrained. This
change adds a better implementation of that in preparation for returning
proper values for position: sticky.
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.
