Commit graph

9 commits

Author SHA1 Message Date
Oriol Brufau
e14556959d
layout: Lay out grid items with a consistent tentative block size (#37981)
When laying out a grid item, the tentative block size that is used to
determine the intrinsic inline sizes was different than the one used in
the containing block for the contents. The latter is now used for both
cases.

Testing: A test is now passing.

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
2025-07-10 19:46:21 +00:00
Oriol Brufau
ff050b71fa
layout: Remove IndependentNonReplacedContents (#37971)
With the work to unify the layout logic for replaced and non-replaced
boxes (#37942), I think the `IndependentNonReplacedContents` enum does
no longer make much sense.

Therefore, this removes `IndependentNonReplacedContents`, merging its
values into `IndependentFormattingContextContents`.

The methods defined on `IndependentFormattingContextContents` can now be
on `IndependentFormattingContext`, in particular this implies that the
layout results of a replaced box will now be cached.

Testing: Unneeded (no behavior change)
This part of #37942

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
2025-07-10 07:46:04 +00:00
Oriol Brufau
c00831f1ed
layout: Remove clearance parameter from BoxFragment::new() (#37921)
Clearance only applies to block-level boxes, so it was unnecessary to
require it as a parameter. Instead, in block layout we can set it using
the new `.with_clearance()` method.

Testing: Unnecessary (no behavior change)

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
2025-07-08 10:04:37 +00:00
Oriol Brufau
fe9d49fccc
layout: Require specific layout info in BoxFragment::new() (#37917)
It was very easy to forget about using `.with_specific_layout_info()` to
set the specific layout info, so it's better to make it a parameter.

In fact this already happened in the past: #36993 fixed the missing
specific layout info for flex items.

This patch fixes it for floats and atomic inlines. It also propagates it
in other cases where not doing so was not a big deal because the
specific layout info was None, but that was a fragile assumption.

Testing: Various WPT improvements
Fixes: #37898

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
2025-07-07 15:25:15 +00:00
Nico Burns
1b5a10a55f
CSS Grid: percentage sizing fixes (#34948)
This applies some fixes for CSS Grid percentage sizing. These fixes are
mostly within Taffy, but there are some changes in Servo to allow it to
communicate whether an item is replaced to Taffy.

It also updates Taffy to v0.8.0. Taffy has switched to a tagged pointer
representation of length/size styles. Much of the diff here is updating
Servo's type conversion code to use the new representation.

---
<!-- 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 OR

---------

Signed-off-by: Nico Burns <nico@nicoburns.com>
2025-06-08 15:17:10 +00:00
Oriol Brufau
1cceb5f6a0
layout: Inform child layout about final block size (#36980)
Before this patch it wasn't possibly to simultaneously support intrinsic
min/max sizes and content alignment in the block axis. For example,
block containers only support the former, and flex containers only the
latter.

The reason is that the final block size was decided by the parent
formatting context *after* performing layout, while content alignment is
performed *during* layout.

To address the problem, this introduces the struct `LazySize`, which
contains the data to resolve the final size, except for the intrinsic
size. Thus the parent formatting context can first create a `LazySize`,
then pass it to the child layout so that (if necessary) it can compute
the final size once the intrinsic one is known, and after layout the
parent formatting context uses it to actually size the child.

This PR just provides the functionality that will be used by follow-ups,
but at this point no layout is using the `LazySize` provided by the
parent, so there shouldn't be any behavior change yet.

Testing: Unnecessary (no behavior change)
This is part of #36981 and #36982

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
2025-05-14 20:35:49 +00:00
Martin Robinson
9bc16482a3
layout: Simplify PositioningContext by having it hold a single Vec (#36795)
`PositioningContext` held two vectors, one inside an `Option`, to
differentiate between the version used for a containing block for all
descendants (including `position: absolute` and `position: fixed`) or
only for `position: absolute` descendants. This distinction was really
hard to reason about and required a lot of bookkeeping about what kind
of `PositioningContext` a layout box's parent expected. In addition, it
led to a lot of mistakes.

This change simplifies things so that `PositioningContext` only holds a
single vector. When it comes time to lay out hoisted absolutely
positioned
fragments, the code then:
 - lays out all of them (in the case of a `PositioningContext` for all
   descendants), or
 - only lays out the `position: absolute` descendants and preserves the
   `position: fixed` descendants (in the case the `PositioningContext`
   is only for `position: absolute`.), or
- lays out none of them if the `PositioningContext` was created for
  box that did not establish a containing block for absolutes.

It's possible that this way of dealing with hoisted absolutes is a bit
less efficient, but, the number of these descendants is typically quite
small, so it should not be significant. In addition, this decreases the
size in memory of all `PositioningContexts` which are created in more
situations as time goes on.

Testing: There is a new WPT test with this change.
Fixes: #36696.

Signed-off-by: Martin Robinson <mrobinson@igalia.com>
2025-05-02 12:20:11 +00:00
haval0
ec88b5d752
layout: Check if root before establishing containing block (#36360)
As per
[w3.org/TR/filter-effects-1#FilterProperty](https://www.w3.org/TR/filter-effects-1/#FilterProperty),
`filter` shouldn't make the root element establish a containing block
for absolute and fixed positioned descendants. `will-change: filter` has
matching behavior.

This PR adds a check for if we are the root element before establishing
such a block.

To know if we are the root element, we look at the `FragmentFlags`
passed in. Previously for our function, these were dummy flags, always
constructed as empty. Thus, this PR also makes sure the correct
FragmentFlags are passed down the chain to the function
`establishes_containing_block_for_all_descendants`.

Testing:
- `/css/filter-effects/filtered-html-is-not-container.html` now passes
- `/css/css-will-change/will-change-fixedpos-cb-003.html` now passes
- Manual tests are working

Fixes: #35391

---------

Signed-off-by: haval0 <56519858+haval0@users.noreply.github.com>
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
2025-04-29 19:19:31 +00:00
Martin Robinson
7787cab521
layout: Combine layout_2020 and layout_thread_2020 into a crate called layout (#36613)
Now that legacy layout has been removed, the name `layout_2020` doesn't
make much sense any longer, also it's 2025 now for better or worse. The
split between the "layout thread" and "layout" also doesn't make as much
sense since layout doesn't run on it's own thread. There's a possibility
that it will in the future, but that should be something that the user
of the crate controls rather than layout iself.

This is part of the larger layout interface cleanup and optimization
that
@Looriool and I are doing.

Testing: Covered by existing tests as this is just code movement.

Signed-off-by: Martin Robinson <mrobinson@igalia.com>
2025-04-19 10:17:03 +00:00
Renamed from components/layout_2020/taffy/layout.rs (Browse further)