| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These two were called by Discord while loading:
- float getTotalLength();
- DOMPoint getPointAtLength(float distance);
|
|
|
|
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
|
|
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).
|
|
This silences a Clang warning.
|
|
|
|
This allows us to perform cross axis alignment without knowing the final
cross size of the flex container.
|
|
We were dropping the result of css_clamp() on the floor, oops!
Let's also mark it [[nodiscard]] so it won't happen again.
|
|
This makes Ladybird stop panicking on websites that try to use WebGL.
|
|
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.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes it so that it always queues a mutation record, even if
`data` is set to the same value. It also makes it follow the spec
steps.
|
|
It must accept taking a copy for DocumentFragment mutation records and
empty vectors created in-place.
|
|
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.
|
|
If the main size is indefinite, that is.
|
|
Pre-compute the effective containing block width in the IFC constructor
and use that throughout.
|
|
|
|
|
|
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.
|
|
At first, these are just wrappers around calculate_intrinsic_sizes().
Eventually, we'll make them do only the work necessary for their
specific size.
|
|
|
|
This protects it from GC.
|
