In quirks mode, the body element expands to fill its parent (the html
element) when height is auto, per the quirks spec section 3.7.
This quirk applies when:
- The document is in quirks mode
- The body element has height: auto
- The body is not absolutely/fixed positioned
- The body is not floated
- The body is not inline-level
The quirks mode percentage height calculation quirk was incorrectly
applied to anonymous boxes (like the internal flex wrapper inside
buttons), causing buttons to collapse to zero height.
Per the quirks spec, the percentage height quirk:
- Only applies to DOM elements, not anonymous boxes
- Does not apply to flex/grid items (they resolve against their
container)
- Does not apply to table-related display types
This patch:
1. Excludes anonymous boxes and flex/grid items from the quirk in
should_treat_height_as_auto()
2. Adds quirks mode percentage height walk-up in
calculate_inner_height() for inline-level boxes
3. Removes the incorrect flex/grid container exclusion from
BlockFormattingContext (the quirk applies to containers, not items)
Add tests to verify:
- Buttons have reasonable height in quirks mode (not collapsed)
- Flex containers with percentage height use quirks walk-up to viewport
- Flex items with percentage height do NOT use quirks walk-up
For `float: left` boxes, we would take the available space into account
and push boxes down as required. This applies that same logic to `float:
right` boxes, where we would previously only compare their offset from
the edge using `>= 0`, which was almost always true.
Fixes#4750.
Previously, buttons with `display: block` and `width: auto` would take
an early return path in compute_width() that set the content width to
fit-content but skipped all margin resolution. This meant `margin: auto`
would not center the button horizontally.
Per CSS 2.1 Section 10.5, percentage heights should only resolve when
the containing block's height is "specified explicitly". This means a
containing block with `height: auto` and `min-height: 50px` does NOT
provide a definite height for percentage resolution - the child's
`height: 100%` should be treated as `auto`.
Previously, we checked `available_space.height.is_indefinite()` to
determine if percentage heights should become auto. However, this
conflated "available layout space" with "containing block height for
percentage resolution" - these are distinct concepts.
Now we check the containing block's `has_definite_height()` flag, which
correctly reflects whether the containing block has an explicit height
property. This handles:
- Anonymous wrapper blocks (skip them to find real containing block)
- Quirks mode (has special percentage height handling)
- Absolutely positioned elements (excluded, different rules apply)
Also update `calculate_inner_height()` to use the containing block's
actual used height when resolving percentages with indefinite available
space, which fixes inline-block and similar cases.
Compute inline-block baselines by traversing into nested block children
to find the last in-flow line box, using correct offsets relative to the
margin box edge.
Also ensure inline-flex and inline-grid containers always derive their
baseline from content (per CSS Align), and add special handling for
<input> elements which have `overflow: clip` in the UA stylesheet but
should still align adjacent text with their internal content.
We had two issues with ::backdrop which this commit fixes:
::backdrop is unique in that it's the previous sibling to its
originating element, instead of a child of it. This means when that
element's layout node is thrown away, the ::backdrop's is not.
A second issue is that if we do a partial layout rebuild, the
originating element's layout node replaces its previous one, but we
would still append a new layout node for ::backdrop to the root, so it
would appear in front of the originating element.
A related issue is that clear_pseudo_element_nodes() got called on the
element after its ::backdrop had been assigned, so it would immediately
lose track of it again.
To solve this, we now always remove the ::backdrop's layout node. If we
need to create a new one, we insert it before the element's layout node
if it has one, otherwise we append as before. This ensures we only ever
have up to one layout node for the ::backdrop, and it appears behind
its originating element.
To support this, create_pseudo_element_if_needed() has a couple of
changes:
- It returns the node that was created.
- The caller can ask it not to insert the node, so that the caller can
do so (which we use so that we can insert it in a specific place)
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.
When calculating the width to use for intrinsic height determination of
flex items in a column layout, we were unconditionally ignoring
percentage min-width and max-width values.
This was overly conservative - when the containing block has a definite
width, percentages can be resolved. We now check if the available width
is definite and resolve percentages in that case.
This fixes the hero layout on https://slack.com/
When computing the width of a box with `width: auto` in an intrinsic
sizing context (min-content or max-content), we previously called
calculate_min/max_content_width() for every such box.
This was wasteful for boxes that don't establish their own formatting
context (e.g. plain divs in a BFC), since their intrinsic width is
simply the intrinsic width of their contents, which we're already
computing as part of the current layout pass.
By only computing intrinsic widths separately for boxes that actually
create a new formatting context (BFC, flex, grid, table, etc.), we
avoid creating redundant throwaway LayoutState objects and formatting
contexts.
For deeply nested structures with `width: max-content` on an ancestor,
this reduces the number of formatting contexts created from O(n) to
O(1), where n is the nesting depth.
For grid items with auto preferred size, stretch/normal alignment, and
no auto margins, the final size is simply the containing block size
minus margin box sizes. We can compute this directly without calling
`calculate_fit_content_width/height`, which triggers expensive intrinsic
sizing layout passes.
Previously, GridFormattingContext handled its own min-height constraints
internally, which caused infinite recursion when min-height was an
intrinsic sizing keyword (e.g., min-height: max-content).
This change moves the responsibility to the parent formatting context
(BFC). When any box establishing an independent formatting context has
auto height but non-auto min-height:
1. BFC measures content height using a throwaway LayoutState
2. If content height < min-height, BFC passes min-height as definite
available height to the child formatting context
3. Child FC runs once with correct constraints, unaware of min-height
Fixes https://github.com/LadybirdBrowser/ladybird/issues/4261 which
is corresponding to stack overflow on https://claude.ai/
This patch fixes an issue where grid items using `grid-area: <name>`
with no matching named grid area or lines would be incorrectly placed
at position 0.
According to https://www.w3.org/TR/css-grid-1/#line-placement:
1. When a `<custom-ident>` doesn't match any named line, placement
should fall back to the first implicit grid line
2. When the same `<custom-ident>` is given for both `grid-*-start` and
`grid-*-end` (which happens with `grid-area: name`), and both fall
back to the same implicit line, the resulting span is 1
Previously, the fallback values were hardcoded to 0 and 1, which placed
items in track 0. The fix changes the fallback to use
`m_explicit_line_count` (the first implicit line index) for both start
and end identifiers. When both reference the same line (start == end),
the existing "both positioned" logic now handles this by setting span=1
and adjusting end accordingly.
`SVGUseElement::referenced_element()` previously passed
`m_href->fragment()` directly to `Document::get_element_by_id()`. URL
fragments are stored in their serialized form, so references to elements
whose IDs contain non-ASCII characters would fail to resolve.
This occured because the abspos containing block is in-between the
containing blocks of two regular ancestors in this case, so it was
being skipped. (The containing block of a table cell is the table
itself, not the table row.)
We already dealt with this for block level children, but inline level
children should also look at the anonymous wrapper's parent's available
space to be able to properly resolve percentage values, for example.
This specifically includes a `!important` for `overflow: clip`, which
makes sure an `<input>`'s contents cannot easily be made to overflow its
boundaries.
The spec says:
> For the purpose of this specification, they all have the same effect
as auto. However, the host language may also take these values into
account when defining the native appearance of the element.
https://drafts.csswg.org/css-ui/#typedef-appearance-compat-special
Firefox at least hides the stepper buttons when this is set.
We were always rendering <symbol> SVG elements, but we should only
render them if they are a child of a <use>'s shadow root. This caused
practically all instances of <symbol> to be drawn at least one time too
many.
Previously, we only supported very basic numbers and a single level of
text positioning support in the `x`, `y`, `dx` and `dy` attributes in
`<text>` and `<tspan>` SVG elements.
This improves our support for them in the following ways:
* Any `length-percentage` or `number` type value is accepted;
* Nested `<text>` and `<tspan>` use the 'current text position'
concept to determine where the next text run should go;
* We expose the attributes' values through the API.
Though we still do not support:
* Applying the `rotate` attribute;
* Applying transformations on a per-character basis.
* Proper horizontal and vertical glyph advancing (we just use the path
bounding box for now).
Use `calculate_inner_height()` and `calculate_inner_width()`, which
account for box-sizing, to resolve the item's size in max-content
contribution calculations.
When we generate pseudo elements, we create anonymous wrappers that
might end up in an InlineNode, even if they have `display: block` set.
This causes them not to be rendered.
Do not rely on inline continuation logic for these anonymous wrappers,
but rather find the first layout parent that's not an InlineNode and
insert it into that.
Fixes#5042.
When an element has `display: contents` and it gets marked for a layout
tree rebuild, we actually have to mark its parent for rebuild as well.
The structure of the parent (and siblings) may change depending on how
the `display: contents` element changes (e.g position, display, etc.)
Originally, 7200b3a16c introduced a two-pass system to determine
hypothetical cross sizes. Later, this was partially reverted in
0084d992d4, but some code was left behind that caused resolution of
percentages in `{min/max}-{width/height}` size constraints not to work.
Through intrinsic sizing, we can potentially end up with a definite
available space for the items in the last FC run. At that point we
should be able to resolve percentages against the available space, but
we were never doing that.
An BlockContainer inside an InlineNode is called from the
`for each in inclusive_subtree_of_type` but is also a fragment
of that InlineNode. Don't count the the Node twice.
When we compute style for elements inside a UA-internal shadow tree that
represent a pseudo-element (e.g ::placeholder), we actually run the
StyleComputer machinery for (host element :: pseudo-element).
While that lets us match the correct selectors, it was incorrectly
applying CSS inheritance, since we'd also then inherit from whatever was
above the host element in the tree.
This patch fixes the issue by introducing an inheritance override in
AbstractElement and then using that to force inheritance from whatever
is actually directly above in the DOM for these elements instead of
jumping all the way up past the host.
This fixes an issue where `text-align: center` on input type=text
elements would render the main text centered but placeholder text was
still left-aligned.
Peek is used to determine if the current chunk is
the last and if so, add trailing box metrics.
For this to work correctly, it must be done only
after calling next(), otherwise peek gives us the
current chunk.
Otherwise the layout tree will still contain the top layer element(s).
Fixes Steam Events & Announcements `<dialog>` modal visually not fully
disappearing upon removal.
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.
Before this change, we always used the flex container's full available
space as the width for intrinsic (height) sizing of flex items.
This meant that flex lines with more than one flex item had their
intrinsic height determined as if they were alone on the line.
For flex row layouts, if we've already determined the flex item's main
size, we now use that as the width to get the intrinsic height.
This leads to more correct layouts, and also avoids some redundant work
since we no longer do unnecessary sizing work with the wrong width (and
can hit cache instead).
