If the layout has been recalculated and the sizes of scrollable
overflow rectangles could have changed, we need to ensure that scroll
offsets remain within the valid range.
Height definiteness is now preserved as intended by CSS-SIZING-3
(assuming I've understood it correctly) and not implicitly granted by
layout algorithms when they assign height.
For the specific special/magical cases where some sizes become definite
during layout, the preceding commits have made them explicit in code.
This fixes a number of flex layout issues where we were previously
resolving percentage values against post-layout flex container heights,
but other browsers don't.
Fixing this function will be quite an undertaking since a *lot* of code
relies on set_content_width() implicitly flipping the definiteness of
the width. It is wrong though, so we do need to fix it eventually.
In particular, these two interesting cases:
- The containing block of an abspos box is always definite from the
perspective of the abspos box.
- When resolving abspos box sizes from two opposing fixed insets,
we now mark those sizes as definite (since no layout was required
to resolve them).
The whole way we lay out SVG content is ad-hoc, so this doesn't follow
any particular spec. However, our viewport transform logic depends on
having definite sizes, so let's just mark them as such for now.
This will be required for percentages to resolve against it correctly
after we make set_content_height() not automatically mark heights as
definite sizes.
The CSS-FLEXBOX-1 spec has a bunch of special cases where sizes are
considered definite after reaching a specific point of the layout
algorithm.
Before this change, we were relying on set_content_width/height also
implicitly marking those content sizes as definite.
To prepare for that implicit behavior going away, this patch makes
the special cases explicit.
Before this change, we were always assigning the calculated height to
each block container after laying it out in BFC.
This should really only happen during intrinsic sizing, since that is
how measurements are communicated to the client there.
With this change "max-width: max-content" is treated as "none" when
the available width is also "max-content". This fix prevents a stack
overflow in the grid track size maximization algorithm by avoiding
recursive calls to calculate_max_width() when determining the maximum
grid container size.
They currently assume the DOM node is an HTMLImageElement with respect
to handling the alt attribute. The HTMLInputElement will require the
same behavior.
Recently, we moved the resolution of CSS properties that do not affect
layout to occur within LayoutState::commit(). This decision was a
mistake as it breaks invalidation. With this change, we now re-resolve
all properties that do not affect layout before each repaint.
This allows positioning a child SVG relative to its parent SVG.
Note: These have been implemented as CSS properties as in SVG 2, these
are geometry properties that can be used in CSS (see
https://www.w3.org/TR/SVG/geometry.html), but there is not much browser
support for this. It is nicer to implement than the ad-hoc SVG
attribute parsing though, so I feel it may make sense to port the rest
of the attributes specified here (which should fix some issues with
viewport relative sizes).
Previously, we were handling viewBoxes/viewports in a slightly hacky
way, asking graphics elements to figure out what viewBox to use during
layout. This does not work in all cases, and can't allow for more
complex SVGs where it is possible to have nested viewports.
This commit makes the SVGFormattingContext keep track of the
viewport/boxes, and it now lays out each viewport recursively, where
each nested `<svg>` or `<symbol>` can establish a new viewport.
This fixes some previous edge cases, and starts to allow nested
viewports (there's still some issues to resolve there).
Fixes#22931
This makes them cheap to move around, since we can store them in a
NonnullOwnPtr instead of memcopying 2584(!) bytes.
Drastically reduces the chance of stack overflow while building the
layout tree for deeply nested DOMs (since tree building was putting
these things on the stack).
This change also exposed a completely unnecessary ComputedValues deep
copy in block layout.
We don't currently calculate the fill- or stroke-boxes of SVG elements,
so for now we use the content- and border-boxes respectively, as those
are the closest equivalents. The test will need updating when we do
support them.
Also, the test is a screenshot because of rendering differences when
applying transforms: a 20px box does not get painted the same as a 10px
box scaled up 2x. Otherwise that would be the more ideal form of test.
Before this change, it was possible for flex lines with negative
remaining space (due to overflowing items) to put a negative amount
of space between items for some values of `justify-content`.
This makes https://polar.sh/SerenityOS look much better :^)
Previously, our code for the fixup of table rows assumed that missing
cells in a table row must be sequential. This may not be true if the
table contains cells have a rowspan greater than one.
When iterating inline level chunks for a piece of text like " hello ",
we will get three separate items from InlineLevelIterator:
- Text " "
- Text "hello"
- Text " "
If the first item also had some leading margin (e.g margin-left: 10px)
we would lose that information when deciding that the whitespace is
collapsible.
This patch fixes the issue by accumulating the amount of leading margin
present in any collapsed whitespace items, and then adding them to the
next non-whitespace item in IFC.
It's a wee bit hackish, but so is the rest of the leading/trailing
margin mechanism.
This makes the header menu on https://www.gimp.org/ look proper. :^)
Step 5 of parsing was always skipped because step 4 continues.
Running step 5 causes some of the denominators to be 0 and causes
divide by zero error in CSSPixelFraction.
SVG Image with height of 0 will cause divide by zero error when
calculating intrinsic aspect ratio of SVGDecoderImageData.
We also get a divide by zero error in AlignContent::SpaceBetween of the
FlexFormatingContext.
During auto track stretching in GridFormatingContext there is a
possibility for count_of_auto_max_sizing_tracks to stay 0.
Prior to this change, we iterated through all fragments within each
PaintableWithLines to resolve the relative position offset. This
happened before transferring the fragments to their corresponding
inline paintables.
With this change, we significantly reduce amount of work by attempting
to resolve relative position offsets only for those contained within
inline paintables.
Performance improvement on https://html.spec.whatwg.org/
Now, instead of resolving "transform" and "transform-origin" during the
construction of the stacking context tree, we do so during the layout
commit.
This is part of a refactoring effort to make the paintable tree
independent from the layout tree.
Now, we will evenly distribute the remaining free space across tracks
using the auto max-tracks sizing function, exactly as the specification
states. Many tests are affected, but they are not visually broken.
Fixes https://github.com/SerenityOS/serenity/issues/22798
There are a bunch of situations where we need to treat cross axis
max-size properties as "none", notably percentage values when the
reference containing block size is an intrinsic sizing constraint.
This fixes an issue where flex items with definite width would get
shrunk to 0px by "max-width: 100%" in case the item itself is an
SVG with no natural width or height.
For consistency, we now use the should_treat_max_width/height_as_none
helpers throughout FFC.
This makes the search/account/cart icons show up in the top right
on https://twinings.co.uk :^)
The paintable tree structure more closely matches the painting order
when fragments are owned by corresponding inline paintables. This
change does not affect the layout tree, as it is more convenient for
layout purposes to have all fragments owned by a block container in
one place.
Additionally, this improves performance significantly on pages with
many fragments, as we no longer have to walk the ancestor chain up
to the closest block container to determine if a fragment belongs
to an inline paintable.
