This state is less static than we originally assumed, and there are
special formatting context-specific rules that say certain sizes are
definite in special circumstances.
To be able to support this, we move the has-definite-size flags from
the layout node to the UsedValues struct instead.
If we wait until after the parent context has laid out the flex
container, abspos children are able to use the final results of the
parent sizing the flex container.
This makes `height:auto` work on abspos children of a flex container.
This disables this system progress bar, and instead creates one
out of pseudo elements, that can be selected and styled with the
::-webkit-progress-bar/value selectors.
Before performing intrinsic sizing layout on a box, we now check if its
containing block has automatic size in the relevant axis, and if so,
we fetch the size of the nearest containing block ancestor with a size.
`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.
