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.
Handling tabs during text shaping caused issues because we tried to
index 'input_glyph_info' whilst iterating until 'glyph_count' and these
can be different sizes.
The difference is due to when one or more characters get
merged into the same glyph when calling 'input_glyph_info' (see
https://lazka.github.io/pgi-docs/HarfBuzz-0.0/classes/glyph_info_t.html).
We don't want to render tabs as they come up as tofu characters so
instead let's strip them out of the text chunk before starting text
shaping.
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.
CSS fragmentation implies 1:N relationship between layout nodes and
paintables. This change is a preparation for implementation of inline
fragmentation where InlinePaintable will be replaced with
PaintableWithLines corresponding to each line.
Always create a new formatting context for <math> elements. Previously
that didn't happen if they only had inline children, e.g. mtable.
This fixes a crash in the WPT MathML test
mathml/crashtests/children-with-negative-block-sizes.html
- 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
Prior to this change, SVGs were following the CSS painting order, which
means SVG boxes could have established stacking context and be sorted by
z-index. There is a section in the spec that defines what kind of SVG
boxes should create a stacking context
https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex
Although this spec is marked as a draft and rendering order described in
this spec does not match what other engines do.
This spec issue comment has a good summary of what other engines
actually do regarding painting order
https://github.com/w3c/svgwg/issues/264#issuecomment-246432360
"as long as you're relying solely on the default z-index (which SVG1
does, by definition), nothing ever changes order when you apply
opacity/filter/etc".
This change aligns our implementation with other engines by forbidding
SVGs to create a formatting context and painting them in order they are
defined in tree tree.
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. :^)
Static position of a box is defined by formatting context type it
belongs to, so let's define this algorithm separately for each FC
instead of assuming FormattingContext::calculate_static_position_rect()
understands how to handle all of them.
Also with this change calculate_static_position_rect() is no longer
virtual function.
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/ :^)
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
This mainly uses forward declarations as appropriate for input element
related files. This reduces the number of targets being built when we
change HTMLInputElement.h from 430 to 44.