`min-width: auto` and `min-height: auto` have special behavior on flex
items. We already handled it in many cases but there were two places
where it was incorrectly treated as 0. This fixes that.
This was a leftover from when ComputedValues stored sizes in Optionals.
Now that we've gotten rid of the "undefined" state, there's no need for
this helper, we can just access the size values directly.
Due to a missing `return` statement, we were creating two anonymous
wrapper blocks around each piece of inline content inside a flex
container.
This had no visual impact, since they ended up with 0x0 dimensions,
but we were wasting a fair bit of time running layout on them.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
When calculating e.g the min-content height of some box, we would only
set its containing block's height to 0 in the temporary formatting
state. The containing block width was not touched at all.
This patch aims to do a bit better by resolving indefinite containing
block sizes to INFINITY before performing intrinsic sizing. We should
probably also find a way to resolve definite containing block sizes,
but I'll leave that for our future selves.
Before this patch, we were justifying based on the content box only,
which led to misalignments along the main axis when items had non-zero
padding, borders or margins.
Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes
end up deciding that some box has a non-finite intrinsic size.
This will create unpleasant results, and may lead to some layout
algorithms looping infinitely, so this patch adds a safeguard where
we simply turn non-finite intrinsic sizes into zero (and complain a
little bit in the debug log.)
I'm not 100% sure this is on-spec, but it seems to me that flex items
that have a specified non-auto cross size should honor that value in
its min-content and max-contribution.
When sizing the flex container under a min-content or a max-content
constraint, flex items with a used flex basis of "content" should be
sized under the same constraint.
Instead, put them in a Vector<OwnPtr<NodeState>>. Each layout node
has a unique index into the vector. It's a simple serial ID assigned
during layout tree construction. Every new layout restarts the sequence
at 0 for the next ICB.
This is a huge layout speed improvement on all content.
We were prematurely resolving the computed size values, which meant
that `auto` values were swallowed before we could resolve them via
the intrinsic aspect ratio (if present)
If the `width` and `height` attributes are provided, we derive the
intrinsic size and ratio from them.
Otherwise, we trace a rectangle around the geometry elements inside
the SVG and use the size of that as the intrinsic size.
This is definitely far from correct, but is still a much better guess
at the intrinsic size than nothing.
This patch adds a separate entry point for this kind of layout.
We override it in BFC to set up initial width/height values for the
BFC root block.
Resulting dimensions are assigned as content_width and content_height
at the end of intrinsic sizing, for each axis, if it's either "auto"
or there's a min-content or max-content constraint in effect.
This fixes an issue where whitespace inside embedded <svg> elements
would create unexpected whitespace text content on the page.
When combined with something like `white-space: pre-wrap`, it ended
up generating a lot of surprising vertical offsets.
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
Before this change, IFC would first generate all of its line boxes
and then measure them. It would then write some of the values into
the state of the IFC's containing block.
We now move that up to BFC::layout_inline_children() instead, which
is a much more natural place to decide metrics for the block.
Instead of allowing FormattingContext to instantiate an IFC for anything
that has inline children, move this logic to BFC.
This is fine, since only BFC deals with blocks having inline children
anyway.
Before, querying any of the four intrinsic sizes would cause us to
calculate all of them (the four being min-content width/height, and
max-content width/height).
Now, the helper functions only calculate the specific intrinsic size
requested. It's then cached at the root formatting context level,
so that it's never calculated twice within the same layout pass.
In cases where flex item cross size is based on the flex line cross
size, the spec specifically says to transfer the *outer* cross size of
the line. We were ignoring the "outer" part.
This patch fixes that by subtracting the cross margins from the size.
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.
