When encountering a box that claims to have block-level children, but
its CSS display type isn't actually "flow" inside, we would previously
crash due to a VERIFY() failure.
However, many sites choke on this due to freestanding table-related
boxes like those created by "table-row" and "table-row-group".
We're supposed to fix those up by wrapping them in a full set of table
boxes during layout tree construction, but that algorithm obviously
isn't working correctly in all cases. So let's work around the crashes
for now, allowing many more sites to load (even if visually incorrect.)
This is a rather monstrous hack, and we should get rid of it as soon as
it's not needed anymore.
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. :^)
Nobody makes undefined Lengths now, (although actually removing
Undefined will come in a later commit) so we can remove this parameter,
and `resolved_or_auto()`/`resolved_or_zero()`.
Until now, some formatting contexts (BFC in particular) have been
assigning size to the root box. This is really the responsibility of the
parent formatting context, so let's stop doing it.
To keep position:absolute working, parent formatting contexts now notify
child contexts when the child's root box has been sized. (Note that the
important thing here is for the child root to have its final used height
before it's able to place bottom-relative boxes.)
This breaks flexbox layout in some ways, but we'll have to address those
by improving the spec compliance of FFC.)
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.
Most of the time, we cannot resolve a `calc()` expression until we go to
use it. Since any `<length-percentage>` can legally be a `calc
()`, let's store it in `LengthPercentage` rather than make every single
user care about this distinction.
Despite looking like it was still needed, it was only used for passing
to other calls to Length::resolved() recursively. This makes the
various `foo.resolved().resolved()` calls a lot less awkward.
(Though, still quite awkward.)
I think we'd need to separate calculated lengths out to properly tidy
these calls up, but one yak at a time. :^)
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.
We now compute the used height of height:auto by measuring from the top
content edge (y=0) to the bottom of the bottommost line box within the
block container.
This fixes an issue where we'd fail to account for the topmost line box
being taller than any of its fragments (which can happen if the
line-height is greater than the height of all fragments on the line.)
This patch breaks FormattingContext::layout_inside() into two functions,
one that creates an independent formatting context (if needed), and
another that calls the former and then performs the inside layout within
the appropriate context.
The main goal here was to make layout_inside() return the independent
formatting context if one was created. This will allow us to defer
certain operations in child contexts until the parent context has
finished formatting the child root box.
Apparently it's not only replaced elements that can have intrinsic
sizes, so let's move this concept from ReplacedBox to Box. To avoid
bloating Box, we make the accessors virtual.
Per the spec, only a BlockContainer" can have line boxes, so let's not
clutter up every Layout::Box with line boxes.
This also allows us to establish an invariant that BFC and IFC always
operate on a Layout::BlockContainer.
Note that if BlockContainer has all block-level children, its line boxes
are not used for anything. They are only used in the all inline-level
children scenario.
Some boxes cannot have children (most commonly replaced elements),
and so there is nothing meaningful inside them to layout.
We now use the can_have_children() flag to quickly skip over such boxes
instead of creating a formatting context and other pointless busywork.
Until now, we've internally thought of the CSS "display" property as a
single-value property. In practice, "display" is a much more complex
property that comes in a number of configurations.
The most interesting one is the two-part format that describes the
outside and inside behavior of a box. Switching our own internal
representation towards this model will allow for much cleaner
abstractions around layout and the various formatting contexts.
Note that we don't *parse* two-part "display" yet, this is only about
changing the internal representation of the property.
Spec: https://drafts.csswg.org/css-display
Instead of trying to layout SVG boxes as if they are regular CSS boxes,
let's invent an "SVG formatting context" and let it manage SVG boxes.
To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox,
and is instead a simple, "inline-block" style BlockBox.
Previously, the method for computing the height of absolutely positioned
replaced elements only invoked the method for non-replaced elements.
That method is now implemented fully enough that it sometimes computed a
height of 0 for replaced elements. This implements section 10.6.5 rule 1
of the CSS spec to avoid that behavior.
Height computation algorithm is actually
different for absolutely positioned boxes
and block formatting contexts (where it doesn't include floats)
Fixes#6408
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7)
by including floating boxes into computation and implements one of the cases
for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
Section 10.6.4 rule 5 of the CSS height property spec outlines a method
to compute the height of an absolutely positioned block when the 'top'
and 'bottom' CSS properties are specified.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
