LibWeb: Carry table cell intrinsic padding as a cell run input - #11029
Merged
kalenikaliaksandr merged 2 commits intoAug 7, 2026
Merged
Conversation
Table cells whose vertical alignment can stretch them (any keyword vertical-align, anonymous flex/grid wrappers, and percentage heights) used to receive their committing inside layout during the row sizing passes, before final row block sizes exist; position_cell_boxes() then patched the stretch into the already-laid-out record. Defer those cells' single committing inside layout to a new driver that runs after row block sizes are final, and feed the row sizing passes from throwaway measurements instead, exactly as percentage-height cells already did in the first pass. The measured automatic block size is adopted into the record so row sizing reads the same values as before, and the pre-layout content block size is restored right before the deferred committing run so the cell's children resolve percentages against the same basis the undeferred layout used (children of a definite-height cell see the specified height, not the adopted automatic one). No layout behavior change. This is preparation for carrying the cell's intrinsic block padding as an input to its own committing run instead of patching it into the record after the fact.
The vertical-alignment stretch used to be patched into the cell's already-laid-out record by position_cell_boxes(): after the cell's committing inside layout finished, the stretch difference was added to the record's block paddings. That leaves cell records mutating after the cell's own run completes, which the future fragment world forbids. Now that stretched cells' committing layout runs after row block sizes are final, the table formatting context can compute the intrinsic block padding up front and hand it to the cell's run as a RootSizingDirectives input, applied to the cell's record before its contents are laid out. position_cell_boxes() no longer writes anything into cell records; it only places them. The padding values and their fixed-point rounding are identical to the old patch (including the order-dependent baseline arm, where the bottom fill absorbs the just-added top padding), so committed output is unchanged: the content-box origin shift the old model created by growing padding after layout is exactly reproduced by growing the padding before a layout whose inputs do not depend on it.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughChangesTable-cell sizing
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant TableFormattingContext
participant CellMeasurement
participant RowSizing
participant FormattingContext
TableFormattingContext->>CellMeasurement: measure deferred cells
CellMeasurement->>RowSizing: provide sizes and baselines
RowSizing->>TableFormattingContext: resolve final row sizes
TableFormattingContext->>FormattingContext: commit cell layout with intrinsic padding
FormattingContext->>TableFormattingContext: return final cell geometry
Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
kalenikaliaksandr
merged commit Aug 7, 2026
99659b2
into
LadybirdBrowser:master
14 of 15 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Table cells whose vertical alignment can stretch them (any keyword
vertical-align, anonymous flex/grid wrappers, and percentage heights)
used to receive their committing inside layout during the row sizing
passes, before final row block sizes exist; position_cell_boxes() then
patched the stretch into the already-laid-out record.
Defer those cells' single committing inside layout to a new driver that
runs after row block sizes are final, and feed the row sizing passes
from throwaway measurements instead, exactly as percentage-height cells
already did in the first pass. The measured automatic block size is
adopted into the record so row sizing reads the same values as before,
and the pre-layout content block size is restored right before the
deferred committing run so the cell's children resolve percentages
against the same basis the undeferred layout used (children of a
definite-height cell see the specified height, not the adopted
automatic one).
No layout behavior change. This is preparation for carrying the cell's
intrinsic block padding as an input to its own committing run instead
of patching it into the record after the fact.