aboutsummaryrefslogtreecommitdiffstats
path: root/components/layout_2020/fragment_tree
Commit message (Collapse)AuthorAgeFilesLines
* Layout 2020: Rename `flow_relative` types to `Logical...` (#30324)Martin Robinson2023-09-123-28/+28
| | | | | | 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`.
* Strict import formatting (grouping and granularity) (#30325)Samson2023-09-116-19/+27
| | | | | * strict imports formatting * Reformat all imports
* remove `extern crate` (#30311)Samson2023-09-085-0/+5
| | | | | | | | | | | * remove extern crate * Update components/script_plugins/lib.rs Co-authored-by: Martin Robinson <mrobinson@igalia.com> --------- Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* build(deps): bump bitflags from 1.3.2 to 2.3.1 (#30273)Martin Robinson2023-09-011-3/+3
| | | | | | Bumps [bitflags](https://github.com/bitflags/bitflags) from 1.3.2 to 2.3.1. - [Release notes](https://github.com/bitflags/bitflags/releases) - [Changelog](https://github.com/bitflags/bitflags/blob/main/CHANGELOG.md) - [Commits](https://github.com/bitflags/bitflags/compare/1.3.2...2.3.1)
* Layout floats as children of their inline ancestors (#30130)Martin Robinson2023-08-221-13/+0
| | | | | | | | | | | | | | | 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.
* Split line layout into two phases (#30089)Martin Robinson2023-08-112-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Try to `use` WebRender types moreMartin Robinson2023-07-101-2/+3
| | | | | The newer versions of WebRender move types around between `webrender` and `webrender_api` and this will reduce the churn during the upgrade.
* Layout 2020: implement clearance as Option<Length>Oriol Brufau2023-06-291-3/+9
| | | | | | | | | | 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.
* Layout 2020: Move all Fragment code to the `fragment_tree` directoryMartin Robinson2023-06-047-3/+941
| | | | | | | | 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.
* Convert some comments into rustdocMartin Robinson2023-06-011-30/+30
| | | | | These were always meant to be rustdoc and converting them makes them show up in the IDE in a more helpful way.
* Better implement getComputedStyle() for positioned insetsMartin Robinson2023-05-092-0/+101
| | | | | | | | 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.
* Detect body elements during layoutMartin Robinson2023-05-042-0/+124
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.