Previously, any SVG geometry attribute change would mark the entire
document layout tree as dirty, triggering a full layout pass even though
only the SVG subtree was affected. This made SVG geometry animations
unnecessarily expensive.
Fix this by stopping `needs_layout_update` propagation at the SVGSVGBox
boundary and tracking dirty SVG roots separately on the Document. When
`update_layout()` finds that only SVG roots need relayout (and the
document layout root is clean), it runs SVGFormattingContext on each
dirty SVG root in a fresh LayoutState and commits the results directly,
bypassing the full document layout pass entirely.
This results in a substantial performance improvement on pages with
animated SVGs, such as https://www.cloudflare.com/,
https://www.duolingo.com/, and our GC graph explorer page.
SVG root elements (SVGSVGBox) have intrinsic sizes determined solely
by their own attributes (width, height, viewBox), not by their
children. SVGFormattingContext::automatic_content_width/height() both
return 0 unconditionally, confirming children never contribute to the
SVG root's intrinsic size from the CSS layout perspective.
This means changes inside an SVG subtree cannot affect ancestor
intrinsic sizes, so we can stop the cache invalidation traversal at
SVG root boundaries, just like we already do for absolutely positioned
elements.
Previously we would resolve font features
(https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence)
per element, while this works for the current subset of the font feature
resolution algorithm that we support, some as yet unimplemented parts
require us to know whether we are resolving against a CSS @font-face
rule, and if so which one (e.g. applying descriptors from the @font-face
rule, deciding which @font-feature-values rules to apply, etc).
To achieve this we store the data required to resolve font features in a
struct and pass that to `FontComputer` which resolves the font features
and stores them with the computed `Font`.
We no longer need to invalidate the font shaping cache when features
change since the features are defined per font (and therefore won't ever
change).
Previously, filter and backdrop-filter were only set when they had
filters (has_filters() returned true). This meant that when these
properties were changed to 'none', the old filter values were never
cleared from computed_values.
This caused elements to incorrectly retain their stacking contexts
after setting filter/backdrop-filter to none, because
establishes_stacking_context() continued to see the old filter values.
CSS allows inline elements with `position: relative` (or other
containing-block-establishing properties) to serve as the containing
block for their absolutely positioned descendants. However, our layout
system stores containing blocks as `Box*`, which cannot represent
inline elements (they are `InlineNode`, not `Box`).
This patch adds a workaround: when computing containing blocks, we
also check if there's an inline element between the abspos element
and its Box containing block that should actually be the CSS
containing block. If found, we store it in a new member called
`m_inline_containing_block_if_applicable` and use it during abspos
layout to:
1. Compute the inline's fragment bounding box as the containing
block rectangle (including padding, per CSS spec)
2. Resolve percentage-based insets against the inline's dimensions
3. Position the abspos element relative to the inline's location
Some details to be aware of:
- The inline containing block search happens in the function
`recompute_containing_block()` by walking DOM ancestors (not layout
tree ancestors, since the layout tree restructures blocks inside
inlines as siblings)
- For pseudo-elements like `::after`, we start the search from the
generating element itself, since it may be the inline containing
block
- Fragment offsets are relative to their block container, so we
translate the computed rect to the abspos element's containing
block coordinate system by accumulating offsets up the ancestor
chain
- When the abspos element uses static position (auto insets), we
don't apply the inline rect translation since static position is
already computed in the correct coordinate system
Long term, we want to refactor our "containing block" concept to
map more cleanly to the spec concept. That means turning it into
a rectangle instead of the box this rectangle was derived from.
That's an invasive change for another day though.
This adds visit_edges(Cell::Visitor&) methods to various helper structs
that contain GC pointers, and makes sure they are called from owning
GC-heap-allocated objects as needed.
These were found by our Clang plugin after expanding its capabilities.
The added rules will be enforced by CI going forward.
Previously we only allowed the viewport itself to be the containing
block for fixed-position elements, but the specs give us a few other
situations. Many of these are the same as for absolute-positioned ones.
When content changes inside a layout node, we now reset intrinsic size
caches only up to the nearest absolutely positioned ancestor, rather
than all the way to the document root.
This optimization is safe because absolutely positioned elements don't
contribute to their ancestors' intrinsic sizes - they are skipped in
min/max content width calculations.
The needs_layout_update flag still propagates to all ancestors so the
document knows layout is needed. Only the cache reset is bounded.
The Transformation class wasn't really accomplishing anything. It still
had to store StyleValues, so it was basically the same as
TransformationStyleValue, with extra steps to convert from one to the
other. So... let's just use TransformationStyleValue instead!
Apart from moving code around, the behavior has changed a bit. We now
actually acknowledge unresolvable parameters and return an error when
we try to produce a matrix from them. Previously we just skipped over
them, which was pretty wrong. This gets us an extra pass in the
typed-om test.
We also get some slightly different results with our transform
serialization, because we're not converting to CSSPixels and back.
...when the style is `none` or `hidden`. `outline-width` is not affected
by `outline-style: none` at all.
In our codebase, that means doing the border-width conversion when
assigning to ComputedValues.
Corresponds to:
2a3d1e4d1009f11f2ef9
Storing these within `LengthPercentage`, `LengthBox`, and `Variant`
over-complicated things.
We also now use the correct `SerializationMode` when serializing `xywh`
and `rect`
We can deduplicate some code by using `assemble_coordinated_value_list`,
also moves this to a method in `ComputedProperties` to be in line with
other values
Computing the font for an element in `compute_font` is premature since
we are yet to apply animated properties - instead we should compute the
value on the fly (with a cache to avoid unnecessary work) to ensure we
are respecting the latest values
Since we resolve any relative lengths at compute time there's no need
for the value to be passed around as a `NumberOrCalculated` and we can
just resolve it within `ComputedProperties::font_variation_settings`.
The only place this is used it is used with value_or so there's no need
to return it is an `Optional`.
This is only used for loading fonts (which occurs during style
computation) so there's no need to store it in `ComputedValues`
The style propagation logic in `NodeWithStyle::apply_style()`
was incomplete for anonymous nodes created during layout
(e.g., within `wrap_in_button_layout_tree_if_needed`).
1. **Non-inherited CSS values** were not being propagated to the
anonymous wrappers.
2. Propagation did not recurse into **nested anonymous wrappers**
(descendants).
This fix adds calls to `propagate_non_inherit_values(child)` and
`child.propagate_style_to_anonymous_wrappers()`, ensuring all computed
styles reach the entire anonymous wrapper hierarchy.
CSS Text 3 gives `text-indent` a couple of optional keywords to control
which lines are affected. This commit parses them, but doesn't yet do
anything with them.
There is no need to recreate this each time we need it when we can
instead create it once and then reuse it.
This is stop-gap since we should resolve colors to their computed forms
as part of StyleComputer::compute_properties
Reduces time spent in ColorResolutionContext::for_layout_node from ~1.1%
to ~0.1% when loading
https://en.wikipedia.org/wiki/2023_in_American_television
By doing this in computed properties rather than InlineLevelIterator we
only do it once per element rather than once per text fragment.
Reduces runtime of this process from ~15% to ~0.2% when loading
https://en.wikipedia.org/wiki/2023_in_American_television
We simplify these at style computation time so there is no need to
maintain them as {Number|Length}OrCalculated
Reduces the time spent in `Length::ResolutionContext::for_layout_node`
from 3.3% to 0.4% when loading
https://en.wikipedia.org/wiki/2023_in_American_television
This applies size, inline-size, and style containment in some cases.
There are other WPT tests for that, but we seem to not implement enough
of containment for this to have an effect so I've not imported those.
Gets us 35 WPT subtests.
Whether an absbox is positioned below or to the right of its previous
sibling in an `InlineFormattingContext` is determined by the
display-outside value before blockification, so we store the
pre-blockification `display` value in `ComputedValues` to access it in
`InlineFormattingContext` and position the box accordingly.
We now also more closely follow the spec when computing values for
font-weight and we now:
- Support relative lengths in `calc()`s
- Properly clamp `calc()`s
- Support relative keywords (e.g. lighter, bolder)
- Respect that font-weight can be a non-integer number.
This does expose a few false positives in the font-weight-computed.html
WPT test. This is because we don't recompute non-inherited font-weight
within `recompute_inherited_style` which means that relative keyword
values can fall out of sync with their parent's value. These previously
passed as we treated `bolder` and `lighter` as aliases for `bold` and
`normal` respectively.
