std::optional<LayoutUnit> opt_fixed_inline_size = std::nullopt;
Nit - the assignment is unnecessary, this'll be initialized to `std::nullopt` automatically.
bool used_block_constraint_at_track_sizing =
`const bool`
if (used_block_constraint_at_track_sizing) {
if (containing_size.block_size == kIndefiniteSize && !is_parallel) {
CHECK_NE(containing_size.inline_size, kIndefiniteSize);
fixed_available_size.block_size = *opt_fixed_inline_size;
} else if (containing_size.inline_size == kIndefiniteSize &&
is_parallel) {
fixed_available_size.inline_size = *opt_fixed_inline_size;
}
}
Is it simpler to lift the `is_parallel` condition and swap cases so you get a straight if/else?
```
if (used_block_constraint_at_track_sizing) {
if (is_parallel) {
if(containing_size.inline_size == kIndefiniteSize) {
fixed_available_size.inline_size = *opt_fixed_inline_size;
}
} else {
// Set the block size to the fixed inline size if the item is orthogonal.
if (containing_size.block_size == kIndefiniteSize) {
CHECK_NE(containing_size.inline_size, kIndefiniteSize);
fixed_available_size.block_size = *opt_fixed_inline_size;
}
}
}
```
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
when needed, which results in column-explicit-placement-002.html
Could you elaborate on which cases "when needed" occurs? Is it just whenever the inline constraint is forced to max-content during track sizing, we will always enforce the same during layout?
const auto writing_mode = GetConstraintSpace().GetWritingMode();
Would it make sense to move this and `opt_fixed_inline_size` closer down to where they're being used?
const auto item_writing_mode = masonry_item.node.Style().GetWritingMode();
nit: could just call this directly in `IsParallelWritingMode` instead of caching. Same goes for `writing_mode`.
Commit-Queue | +1 |
to the items max content [1].
Alison Mahernit: "item's"
Done
when needed, which results in column-explicit-placement-002.html
Could you elaborate on which cases "when needed" occurs? Is it just whenever the inline constraint is forced to max-content during track sizing, we will always enforce the same during layout?
Yeah essentially in the same cases as [1]. I've added to the description to call that out
std::optional<LayoutUnit> opt_fixed_inline_size = std::nullopt;
Nit - the assignment is unnecessary, this'll be initialized to `std::nullopt` automatically.
Done
const auto writing_mode = GetConstraintSpace().GetWritingMode();
Would it make sense to move this and `opt_fixed_inline_size` closer down to where they're being used?
Done
const auto item_writing_mode = masonry_item.node.Style().GetWritingMode();
nit: could just call this directly in `IsParallelWritingMode` instead of caching. Same goes for `writing_mode`.
Yeah we could, but this is one where I think it is somewhat helpful to name these so it is clear which is the container and which is the item
bool used_block_constraint_at_track_sizing =
Alison Maher`const bool`
Done
if (used_block_constraint_at_track_sizing) {
if (containing_size.block_size == kIndefiniteSize && !is_parallel) {
CHECK_NE(containing_size.inline_size, kIndefiniteSize);
fixed_available_size.block_size = *opt_fixed_inline_size;
} else if (containing_size.inline_size == kIndefiniteSize &&
is_parallel) {
fixed_available_size.inline_size = *opt_fixed_inline_size;
}
}
Is it simpler to lift the `is_parallel` condition and swap cases so you get a straight if/else?
```
if (used_block_constraint_at_track_sizing) {
if (is_parallel) {
if(containing_size.inline_size == kIndefiniteSize) {
fixed_available_size.inline_size = *opt_fixed_inline_size;
}
} else {
// Set the block size to the fixed inline size if the item is orthogonal.
if (containing_size.block_size == kIndefiniteSize) {
CHECK_NE(containing_size.inline_size, kIndefiniteSize);
fixed_available_size.block_size = *opt_fixed_inline_size;
}
}
}
```
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[Masonry] Fix column-explicit-placement-002.html
column-explicit-placement-002.html was added in CL:6641991. This test
was failing because during track sizing, when we calculated the block
contribution for the orthogonal item, its inline constraint was forced
to the item's max content [1].
However, at layout time, we don't enforce this same constraint. This
works in Grid because we are constrained by the final track sizes in
both directions, but in masonry, we only constrain by tracks in one
direction.
This change ensures that we enforce the same constraint at layout time
when needed (see [1] for the cases where this is needed), which results
in column-explicit-placement-002.html rendering similarly to grid.
The reference file was also updated because the container has a width of
200px in the test file, which incorrectly didn't match the reference.
[1]
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/masonry/masonry_layout_algorithm.cc;l=745-761?q=ComputeMasonryItemBlockContribution&ss=chromium
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |