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.
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.
When resolving a percentage min-width or min-height size against a
containing block currently under a min-content constraint, we should act
as if the containing block has zero size in that axis.
This is technically "undefined behavior" per CSS 2.2, but it seems
sensible to mirror the behavior of max-height in the same situation.
It also appears to match how other engines behave.
Fixes#19242
Although DistinctNumeric, which is supposed to abstract the underlying
type, was used to represent CSSPixels, we have a whole bunch of places
in the layout code that assume CSSPixels::value() returns a
floating-point type. This assumption makes it difficult to replace the
underlying type in CSSPixels with a non-floating type.
To make it easier to transition CSSPixels to fixed-point math, one step
we can take is to prevent access to the underlying type using value()
and instead use explicit conversions with the to_float(), to_double(),
and to_int() methods.
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.
These are only used during layout, and always within formatting context
code, so we might as well put them in FormattingContext and avoid having
to pass the LayoutState around all the time.
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.
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.
Instead of special-casing FlexFormattingContext in the intrinsic sizing
layout helpers, add FormattingContext::automatic_content_width() and let
each context subclass decide what that means.
No behavior change here, just moving this responsibility.
Change `compute_auto_height_for_block_level_element` to use max height
(`m_automatic_content_height` produced from TFC) for tables with auto
height which is more correct behaviour than treating them like block
containers.
Introduce `table_box()` function that returns table formatting
context root box casted to `TableBox` similar to how it's done
in other formatting contexts like `root()` in BFC and
`flex_container` in FFC. And replace `context_box()` calls
in TFC with calls to `table_box()`.
Fixup rule that table roots need to be wrapped in anonymous
block boxes need to be implemeted instead of having `TableBox`
inherited from `BlockContainer`.
Change column distribution to take in account is_length() and
is_percentage() width values instead of treating all cells like
they have auto width by implementing it in the way described
in CSS Tables 3 spec:
https://www.w3.org/TR/css-tables-3/#width-distribution-algorithm
distribute_width_to_column() is structured to follow schema:
w3.org/TR/css-tables-3/images/CSS-Tables-Column-Width-Assignment.svg
It is not possible to use width of containing block to resolve
cells width because by the time compute_table_measures() is
called row width is not known yet.
Previously when there was no difference between the sum of the
max and min-widths of all columns of a table, it would result in a NaN
value being set as the column's width as there was a division by 0.
This would result in 2+ column tables being reduced to only 1 column.
Fixes the y-position of rows when indicated through the display
attribute `table-row`. Previously there was no y-offset between rows and
so they would overlap.
This change makes outer min-content width and outer max-content
width for cells to be calculated in the way specifed in the spec:
- The outer min-content width of a table-cell is max(min-width,
min-content width) adjusted by the cell intrinsic offsets.
- The outer max-content width of a table-cell in a non-constrained
column is max(min-width, width, min-content width, min(max-width,
max-content width)) adjusted by the cell intrinsic offsets.
- The outer max-content width of a table-cell in a constrained
column is max(min-width, width, min-content width, min(max-width,
width)) adjusted by the cell intrinsic offsets.
Here I try to address bug where content of table overflows
it's width (hacker news is an example of such site) by
reimplementing some parts of table formatting context.
Now TFC implements first steps of:
https://www.w3.org/TR/css-tables-3/#table-layout-algorithm
but column width and row height distribution steps are
still very incomplete.
This is a big and messy change, and here's the gist:
- AvaliableSpace is now 2x AvailableSize (width and height)
- Layout algorithms are redesigned around the idea of available space
- When doing layout across nested formatting contexts, the parent
context tells the child context how much space is available for the
child's root box in both axes.
- "Available space" replaces "containing block width" in most places.
- The width and height in a box's UsedValues are considered to be
definite after they're assigned to. Marking something as having
definite size is no longer a separate step,
This probably introduces various regressions, but the big win here is
that our layout system now works with available space, just like the
specs are written. Fixing issues will be much easier going forward,
since you don't need to do nearly as much conversion from "spec logic"
to "LibWeb logic" as you previously did.
Instead of formatting contexts flailing around to figure out from the
"inside" how much space is available on the "outside", we should
provide the amount of available space in both axes as an input to run().
This basically means that when something creates a nested formatting
context, the parent context is responsible for telling the nested context
how much space is available for layout. This information is provided
immediately when invoking run().
Note that this commit doesn't pass accurate values in all cases yet.
This first step just makes it build, and passes available values in some
cases where getting them was trivial.
This function should return the automatic height of the formatting
context's root box.
Until now, we've been relying on some magical handshakes between parent
and child context, when negotiating the height of child context root
boxes. This is a step towards something more reasonable.
Previously, we had three layout modes:
- Normal:
- Everything uses the computed values from CSS.
- MinContent:
- Containing blocks act as if they have 0 width.
- All line breaking opportunities are taken.
- MaxContent:
- Containing blocks act as if they have infinite width.
- Only forced line breaks are accepted.
The above was based on a set of misunderstandings of CSS sizing.
A major problem with the above was that *all* containing blocks
behaved differently during intrinsic size layout, not just the
relevant one.
With this patch there are only two layout modes:
- Normal:
- Everything uses the computed values from CSS.
- IntrinsicSizeDetermination:
- One or more boxes have size constraints applied.
There are two size constraints per layout box, set here:
- FormattingState::NodeState::width_constraint
- FormattingState::NodeState::height_constraint
They are of type SizeConstraint and can be one of None, MinContent,
or MaxContent. The default is None.
When performing an IntrinsicSizeDetermination layout, we now assign
a size constraint to the box we're trying to determine the intrinsic
size of, which is then honored by using two new helpers to query
the dimensions of containing blocks:
- FormattingContext::containing_block_width_for(Box)
- FormattingContext::containing_block_height_for(Box)
If there's a relevant constraint in effect on the Box, the size of
its containing block is adjusted accordingly.
This is essentially an implementation of the "available space"
constraints from CSS-SIZING-3. I'm sure some things will break from
this, and we'll have to deal with that separately.
Spec: https://drafts.csswg.org/css-sizing-3/#available
Instead of using Optional<LengthPercentage>, we now use LengthPercentage
for these values. The initial values are all `auto`.
This avoids having to check `has_value()` in a ton of places.
This gets us a bit closer to the recommended algorithms in CSS 2.2 and
CSS Table Module 3.
A couple of table heavy websites (e.g. news.ycombinator.com,
html5test.com, etc.) now look quite okay. :^)
The old mode names, while mechanically accurate, didn't really reflect
their relationship to the CSS specifications.
This patch renames them as follows:
Default => Normal
AllPossibleLineBreaks => MinContent
OnlyRequiredLineBreaks => MaxContent
There's also now an explainer comment with the LayoutMode enum about the
specific implications of layout in each mode.
This patch adds a map of Layout::Node to FormattingState::NodeState.
Instead of updating layout nodes incrementally as layout progresses
through the formatting contexts, all updates are now written to the
corresponding NodeState instead.
At the end of layout, FormattingState::commit() is called, which
transfers all the values from the NodeState objects to the Node.
This will soon allow us to perform completely non-destructive layouts
which don't affect the tree.
Note that there are many imperfections here, and still many places
where we assign to the NodeState, but later read directly from the Node
instead. I'm just committing at this stage to make subsequent diffs
easier to understand.
The purpose of this new object will be to keep track of various states
during an ongoing layout.
Until now, we've been updating layout tree nodes as we go during layout,
which adds an invisible layer of implicit serialization to the whole
layout system.
My idea with FormattingState is that running layout will produce a
result entirely contained within the FormattingState object. At the end
of layout, it can then be applied to the layout tree, or simply queried
for some metrics we were trying to determine.
When doing subtree layouts to determine intrinsic sizes, we will
eventually be able to clone the current FormattingState, and run the
subtree layout in isolation, opening up opportunities for parallelism.
This first patch doesn't go very far though, it merely adds the object
as a skeleton class, and makes sure the root BFC has one. :^)
This property represents the CSS content size, so let's reduce ambiguity
by using the spec terminology.
We also bring a bunch of related functions along for the ride.
A lot of this is quite ugly, but it should only be so until I remove
Length::Type::Percentage entirely. (Which should happen later in this
PR, otherwise, yell at me!) For now, a lot of things have to be
resolved twice, first from a LengthPercentage to a Length, and then
from a Length to a pixel one.
