Commit graph

6 commits

Author SHA1 Message Date
Nico Burns
cc64da821b Set default back to 0%
Signed-off-by: Nico Burns <nico@nicoburns.com>
2025-05-30 19:12:53 +01:00
Nico Burns
f3debd80bd Communicate whether an element is replaced to Taffy
Signed-off-by: Nico Burns <nico@nicoburns.com>
2025-05-30 19:05:57 +01: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)