As it turns out, Layout::TreeBuilder never managed to wrap text within
table boxes in anonymous wrapper boxes, since it relied on checking
text_for_rendering(), and that was never initialized during that early
stage of tree building.
This patch fixes the issue by making text_for_rendering() compute the
(potentially collapsed) text lazily when called.
Note that the test included with this patch is still totally wrong,
but that is now a TFC problem rather than a TreeBuilder problem. :^)
Cell percentage widths are relative to table width, not containing
block width. If the table width is auto, there isn't a normative
specification, only a brief mention that the user agent should try to
meet it.
As a starting point, we increase the width of the table such that it's
sufficient to cover min-width of cells with a percentage width. This
matches the behavior of other browsers, at least for simple cases.
This ensures that min-content contributions from cells with no content
are computed using their calculated values, which are never considered
for min-content before then. The specification diverges from column
measures algorithm, which doesn't use specified width of cells anywhere.
The used width is already a content width, which doesn't include
borders. Border widths should be subtracted from the specified width
instead, since that initially specifies the total width including
borders, for consistent comparison. Also handle table box padding as an
additional fix.
On style update, we have to preserve the invariant established when we
built the layout tree - some properties are applied to the table wrapper
and the table box values are reset to their initial values.
This also ensures that the containing block of a table box is always a
table wrapper, which isn't the case if we set absolute position on the
box instead of the wrapper.
Fixes#19452.
Adding undistributable space right before setting the content width is
incorrect when it's a percentage. Follow the specification and add it to
GRIDMIN and GRIDMAX instead.
The shortcut we put in place didn't resolve percentage widths and
ignored border spacing. We can still return early after we compute the
width per the specifications.
Compute the contributions to a spanning cell width from each cell in the
span. This better handles uneven column widths, since each cell
contribution is proportional with its own width as opposed to the own
width of the first cell in the span.
This better matches the behavior of other browsers and further aligns
with the specification.
With multi-line text cells, we don't reliably know the height would stay
the same as the one set by the independent format context run. In such
situations, we can end up with a table box which is sized inconsistently
with the grid boxes of the table due to differences in line breaks.
In compute_table_box_width_inside_table_wrapper, we should only consider
available_width when it's valid. Values which come from {min,
max}-content constraints aren't meaningful and shouldn't be considered
for the cap.
Add logic to compute {min, max}-height and use min-height when
calculating table height, per specifications.
Fixes some issues with phylogenetic tree visualizations on Wikipedia.
The specification isn't explicit about it, but the contribution we
compute should be distributed to all columns, not just the first one.
The first reason for it is symmetry, it doesn't make sense for the
increased width of the spanning column to only affect the first column
in the span.
The second reason is the formula for the cell contribution, which is
weighted by the non-spanning width of the cell relative to the total
width of the columns in the same row. This only covers a fraction of the
gap, in order to fully cover it we have to add it to all columns in the
span. For this to be exactly the case when the columns don't all have
the same width, we'd have to add additional weighting based on the width
ratios, but given that the specification doesn't suggest it at all we'll
leave it out for now.
Instead of just measuring the layout viewport, we now measure overflow
in every box that is a scroll container.
This has the side effect of no longer creating paintables for layout
boxes that didn't participate in layout. (For example, empty/anonymous
boxes that were ignored by flex itemization.)
Such boxes are now marked as "(not painted)" in the layout tree dumps,
as they have no paintable to dump geometry from.
Since there are no table-specific boxes anymore it would be nice to
output their types additionally in layout dump so we can tell table
boxes from "regular" boxes.
Solves conflict in layout tree "type system" when elements <label> (or
<button>) can't have `display: table` because Box can't be
Layout::Label (or Layout::ButtonBox) and Layout::TableBox at the same
time.
In order to fix this, I also had to reorganize the code so that we
create an independent formatting context even for block-level boxes
that don't have any children. This accidentally improves a table
layout test as well (for empty tables).
If the parent BFC can come up with a nice stretch-fit width for the flex
container, it will have already done so *before* even entering flex
layout. There's no need to do it again, midway through the flex layout
algorithm.
This wasn't just unnecessary, but we were also doing it incorrectly and
not taking margins into account when calculating the amount of available
space for stretch-fit. This led to oversized flex containers in the
presence of negative margins.
Fixes#18614
Width of table wrapper need to be set to to calculate width of table
box inside. Otherwise TFC will set wrong width assuming width of
containing block is 0.
This patch does three things:
- Factors out the code that determines whether a box will create a new
formatting context for its children (and which type of context)
- Uses that code to mark all formatting context roots in layout tree
dumps. This makes it much easier to follow along with layout since
you can now see exactly where control is transferred to a new
formatting context.
- Rebaselines all existing layout tests, since the output format has
changed slightly.
This fix resolves issue where calculating the min size of a block could
result in incorrect value if width of the block's children was
compensated by margins to fit into container width (which is equal to 0
during min size calculation).
This commit implements following missing steps in table layout:
- Calculate final table height
- Resolve percentage height of cells and rows using final table height
- Distribute avilable height to table rows
If total max columns width (grid_max) is zero then available width
should be divided equally between columns. Previously there was
division by zero: `column.max_width / grid_max`.
Previously, the minimum height of a table row was calculated based
on the automatic height of the cells inner layout. This change makes
computed height of a cell boxes also be considered if it has definite
value.
