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).
We were already doing this within `compute_property_values` where
we resolved most relative lengths but the remainder was instead
incorrectly using the font's line-spacing
Previously, we were collapsing whitespace in Layout::TextNode and then
passed the resulting string for further processing through ChunkIterator
-> InlineLevelIterator -> InlineFormattingContext -> LineBuilder ->
LineBoxFragment -> PaintableFragment. Our painting tree is where we deal
with things like range offsets into the underlying text nodes, but since
we modified the original string, the offsets were wrong.
This changes the way we generate fragments:
* Layout::TextNode no longer collapses whitespace as part of its
stored "text for rendering", but moves this logic to ChunkIterator
which splits up this text into separate views whenever whitespace
needs to be collapsed.
* Layout::LineBox now only extends the last fragment if its end offset
is equal to the new fragment's start offset. Otherwise, there's a
gap caused by collapsing whitespace and we need to generate a
separate fragment for that in order to have a correct start offset.
Some tests need new baselines because of the fixed start offsets.
Fixes#566.
This means that we now calculate the inner width correctly for `display:
inline-block` nodes when we have `box-sizing: border-box` and
`min-width`, as we would previously assume these dimensions were all `0`
...when `LengthOrAutoOrCalculated` holds calculated value. We were
incorrectly assuming that if contained value is not auto, then it must
be a length.
Fixes crashing on https://hollowknightsilksong.com/
This change removes premature reset of
`block_container_y_position_update_callback`. Also makes callback
private in `BlockMarginState`, because resetting it independently of
currently accumulated margins is incorrect.
Lots of test expectations are updated, but there is no visual
difference.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/6074
...selector. Grammar per spec: `::slotted( <compound-selector> )`, so
we should reject selector as invalid if first compound selector is
followed by something else.
This change makes layout more correct on https://www.rottentomatoes.com/
If we were calculating the static position for an absolutely positioned
inline box that resides in the last line of its containing block, we
would not have yet provided the fragments in that line with their
final positions. Additionally, we would always move the box beneath the
fragment, which was incorrect.
Fixes#5867.
Inline nodes in our layout tree have a position, so let's show it. By
centralizing the logic for this, block nodes now lose their redundant
'content-size' dump info which is already part of the box model dump.
All fragments inside an atomic inline box should stay within that box,
otherwise we'll screw up the paint order and paint them behind things
that they're supposed to be on top of.
This fixes an issue with inline-block content not appearing on sites
like Google Docs and Reddit, among others.
There are some nuances to creating these wrappers, such as manually
propagating certain text styles that are not inherited by default. We
already have the logic for this in
`NodeWithStyle::create_anonymous_wrapper()`, so reuse that method in our
implementation of the button layout.
Fixes applying certain text styles (such as `text-decoration`) to the
text of a `<button>`.
...by another GFC. When searching for grid item that contains an
abspos box positioned relative to GFC, it's incorrect to assume that the
closest ancestor box whose parent establishes GFC is always the one we
are looking for, because there may be non-positioned GFC in between.
Fixes regression introduced in 80c8e78.
For button layouts, we were overriding the computed `width` value with
`fit-content` in `TreeBuilder::wrap_in_button_layout_if_needed()`. But
the spec asks us to set the _used value_ instead, so we now actually
calculate the fit-content width and set the box' content width to it.
Fixes#2516.
This suits the spec a bit better, and exposes the fact that we were
allowing `::ImageButton` to use the button layout although it is never
specified that it should do so. Tests were rebaselined for this.
Flex/grid items are always blockified (have their CSS display forced
into "block") by style computation.
We were doing this by looking at the CSS display of the parent. However,
if the parent has `display: contents`, we must look at the *grandparent*
instead.
This corrects the layout of buttons underneath Reddit article cards.
Before this change, `layout_absolutely_positioned_element()` in GFC
had an assumption that all contained by grid container abspos boxes were
also direct children of the grid container. This change adds handling
for the cases when it's not true and, in order to identify grid area
abspos box belongs to, we have to find ancestor grid item.
When a subtree is projected through a slot, its root now inherits style
from the slot's parent, rather than the parent of the unprojected root.
This fixes a ton of subtle issues, and is very noticeable on Reddit.
When converting rotate transform functions `sin` and `cos` can sometimes
be inaccurate. To avoid these inaccuracies we:
- Mod the angle to minimise inaccuracies in the first place.
- Discard tiny (smaller than epsilon) values returned by `sin` and
`cos` as inaccuracies.
This is in line with other browsers (e.g. Gecko and WebKit).
CSS grid specification states that for grid items with a replaced
element and a percentage preferred size or maximum size, the percentage
should be resolved against 0 during content-based minimum size
calculation. This makes sense, as it prevents replaced items from
overshooting their grid track while intrinsic track sizes are
calculated, and allows later track size resolution steps to scale
replaced items to fit their grid track.
FFC expects parent formatting context to mark size as definite if that's
the case, because otherwise it cannot figure cross line size correctly.
Fixes incorrect alignment when FFC is nested in GFC.
Progress on https://web.telegram.org/a/ layout.
