This begins to address #26625 by properly applying CSS variables during
keyframe computation and no longer using `apply_declarations`. Instead,
walk the declarations, combining them into IntermediateComputedKeyframe,
maintaining declarations that modify CSS custom properties. Then compute
a set of AnimationValues for each keyframe and use those to produce
interpolated animation values.
layout_2020: Implement support for backface-visibility
<!-- 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] There are tests for these changes
<!-- 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. -->
Add support for getComputedStyle() to layout_2020
These changes add support for `getComputedStyle()` to layout_2020.
---
<!-- 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] There are tests for these changes
<!-- 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 implementation is more-or-less on par with the one from layout_2013
and in some cases better. There are still some cases where we don't
return the correct "resolved value," but this is enough to test
animations and transitions.
Add support for tracking containing blocks when doing inline layout.
This requires setting up a PositioningContext for inline boxes when
necessary. Instead of using the PositioningContext helper methods
and we reuse the contexts between line breaks.
Fixes#25279.
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.
