When aspect-ratio is degenerate (e.g. 0/1 or 1/0) we should
fallback to the same behaviour as `aspect-ratio: auto` according to spec
This commit explicitly handles this case and fixes five WPT test in
css/css-sizing/aspect-ratio (zero-or-infinity-[006-010])
This condition was included to implement flex containers with auto
height, but it actually can reset the definitive height to 0 for inline
blocks with only replaced elements such as an SVG. Removing the
condition does not break any in-tree test, so let's improve the
situation on the SVG side of things for now.
These files seem to have been marked as executable by error.
Found by running the command:
find \( -name WPT -or -name Toolchain -or -name Build \) \
-prune -or -executable \! -type d -print \
| grep -Pv '\.(sh|py)$'
The reason we were keeping track of the pre-shaping buffer was to know
where we had tab characters in the input. This is a very strange way of
doing that, but since it broke the web, let's patch it up quickly.
Follow-up to #1870 which broke text layout on many web pages.
This fixes a browser crash as experienced on Wikipedia when encountering
the ≠ entity. As a side-effect, this also affects some tab-align and
-wrap tests.
Per css-ui-4, setting `appearance: none` is supposed to suppress the
creation of a native-looking widget for stuff like checkboxes, radio
buttons, etc.
This patch implements this behavior by simply falling back to creating
a layout node based on the CSS `display` property in such cases.
This fixes an issue on the hey.com imbox page where we were rendering
checkboxes on top of sender profile photos.
On any `display: list-item` Node a CSS pseudo element (`::marker`) needs
to be created. This commit allows the ::maker pseudo element to be
nested within other pseudo elements (e. g. ::before or ::after).
This fixes this WPT test:
http://wpt.live/css/CSS2/generated-content/after-content-display-003.xht
InlinePaintable was an ad-hoc paintable type required to support the
fragmentation of inline nodes across multiple lines. It existed because
there was no way to associate multiple paintables with a single layout
node. This resulted in a lot of duplicated code between PaintableBox and
InlinePaintable. For example, most of the CSS properties like
background, border, shadows, etc. and hit-testing are almost identical
for both of them. However, the code had to be duplicated to account for
the fact that InlinePaintable creates a box for each line. And we had
quite many places that operate on paintables with a code like:
```
if (box.is_paintable_box()) {
// do something
} else (box.is_inline_paintable()) {
// do exactly the same as for paintable box but using InlinePaintable
}
```
This change replaces the usage of `InlinePaintable` with
`PaintableWithLines` created for each line, which is now possible
because we support having multiple paintables per layout node. By doing
that, we remove lots of duplicated code and bring our implementation
closer to the spec.
- Include vertical border spacing in row group offset calculation so
that they are axis-aligned with child row/cell elements. This makes it
so there isn't horizontal and vertical overflow caused by child
row/cell elements.
- Include horizontal border spacing in tr width calculations. This makes
it so tr elements don't have overflow anymore when there are multiple
columns.
- Apply vertical caption offset to row group top offset.
- Don't double-count top padding when calculating vertical offset for
tr and row groups.
- Add support for placement of abspos items into track formed by last
line and padding edge of grid container
- Correctly handle auto-positioned abspos items by placing them between
padding edges of grid container
Fixes crashing on https://wpt.live/css/css-grid/abspos/positioned-grid-descendants-001.html
The video was accidentally removed in commit d5ba665f89.
This adds the video back to the LibWeb/Text/data folder, and validates
that the video loads in the test that depends on it loading.
Before this change, we transferred the input element's line-height to
both the editable text *and* the placeholder. This caused some strange
doubling of the effective line-height when the editable text was empty,
pushing down the placeholder.
When the flex container is sized under a min-content constraint in the
main axis, any flex items with a percentage main size should collapse
to zero width, not take up their own intrinsic min-content size.
This is not in the spec, but matches how other browsers behave.
Fixes an issue where the cartoons on https://basecamp.com/ were way
too large. :^)
We were already allowing intrinsic height layout to see definite widths,
and I can't think of a reason *not* to allow it the other way around.
More importantly, this fixes an issue where things with an aspect ratio
didn't have a height to resolve against before.
Makes the logo show up on https://basecamp.com/ :^)
This is what the spec tells us to do:
The root element’s display type is always blockified,
and its principal box always establishes an independent
formatting context.
Additionally, a display of contents computes to block
on the root element.
Spec link: https://drafts.csswg.org/css-display/#rootFixes#1562
It's possible to resolve box's height without doing inner layout, when
computed value is not auto. Doing that fixes height resolution, when box
with percentage height has containing block with percentage height.
Before:
- resolve used width
- layout box's content
- resolve height
After:
- resolve used width
- resolve height if treated as not auto
- layout box's content
- resolve height if treated as auto
..and delay static position calculation in IFC until trailing
whitespace are removed, because otherwise it's not possible to correctly
calculate x offset.
Containing block for abspos grid items depends on their grid placement:
- if element has definite grid position, then corresponding grid area
should be used as a containing block
- if element does not have definite grid position, then padding edge of
grid container should be used as a containing block
So offset should be adjusted for paddings only for boxes without
definite grid position.
Our current text iterator is not aware of multi-code point graphemes.
Instead of simply incrementing an iterator one code point at a time, use
our Unicode grapheme segmenter to break text into fragments.
When a block container has `clear` set and some clearance is applied,
that clearance prevents margins from adjoining and therefore resets
the margin state. But when a floating box has `clear` set, that
clearance only goes between floating boxes so should not reset margin
state. BlockFormattingContexts already do that correctly, and this PR
changes InlineFormattingContext to do the same.
Fixes#1462; adds reduced input from that issue as test.
Function is defined as `round(<rounding-strategy>?, A, B?)`
With this change resolved type is `typeof(resolve(A))`, instead of
`typeof(A)`.
For example `round(up, 20%, 1px)` with 200px percentage basis is now
correctly resolved in 40px instead of 40%.
Progress on https://www.notion.so/ landing page.
The `calculate_inner_width()` and `calculate_inner_height()` resolve
percentage paddings using the width returned by
`containing_block_width_for()`. However, this function does not account
for grids where the containing block is defined by the grid area to
which an item belongs.
This change fixes the issue by modifying `calculate_inner_width()` and
`calculate_inner_height()` to use the already resolved paddings from the
layout state. Corresponding changes ensure that paddings are resolved
and saved in the state before box-sizing is handled.
As a side effect, this change also improves abspos layout for BFC where
now paddings are resolved using padding box of containing block instead
of content box of containing block.
Fixes yet another case of GFC bug, where Node::containing_block() should
not be used for grid items, because their containing block is grid area
which is not represented in layout tree.
Although the parameter is named "available size," it is always supposed
to represent the containing block size whenever it has a definite value.
Therefore, it is possible to simply use this value instead of performing
a containing block lookup.
This change actually improves correctness for grid items whose
containing block is defined by the grid area, as
`Node::containing_block()` does not account for this.
Change try_compute_width() to check whether min-width/max-width or width
is auto instead of always using `computed_values.width()`.
`grid/min-max-content.html` test is affected but it's progression.
Before this change, a formatting context was responsible for layout of
absolutely positioned boxes whose FC root box was their parent (either
directly or indirectly). This only worked correctly when the containing
block of the absolutely positioned child did not escape the FC root.
This is because the width and height of an absolutely positioned box are
resolved based on the size of its containing block, so we needed to
ensure that the containing block's layout was completed before laying
out an absolutely positioned box.
With this change, the layout of absolutely positioned boxes is delayed
until the FC responsible for the containing block's layout is complete.
This has affected the way we calculate the static position. It is no
longer possible to ask the FC for a box's static position, as this FC's
state might be gone by the time the layout for absolutely positioned
elements occurs. Instead, the "static position rectangle" (a concept
from the spec) is saved in the layout state, along with information on
how to align the box within this rectangle when its width and height are
resolved.
