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.
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).
layout_2020: Use ArcRefCell in the fragment tree
This will allow mutability which is useful for things like animations.
<!-- 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
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they should 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. -->
Partial text decoration support for layout 2020
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#25166
- [X] There are tests for these changes
When calculating scrolling overflow calculation we cannot currently use
the actual containing block in all cases. This change increases the
amount that we do use the containing block.
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 allows rendering stacking context content in the proper order. We
also need to add a new pseudo stacking context for atomic inlines in
order to preserve proper rendering order in some cases.
This adds very rudimentary support for paint order in stacking context.
In particular z-index is now handled properly, apart from issues with
hoisted fragments.
This adds an intermediary data structure that allows the display list
builder to move through the fragment tree in stacking context painting
order. Spatial nodes are built during this phase and all display list
items are added to the end of the display list.
This isn't correct yet, but it is necessary to give a value in order for
scrolling from script to work. Later this should give an accurate
content box response as well as work for non-root elements.
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.
