Rather than splitting the Iterator type and its AOs into two files,
let's combine them into one file to match every other JS runtime object
that we have.
This is an editorial change in the ECMA-262 spec. See:
ff60140
In doing so, as the new name implies, callsites are updated to pass in
an IteratorRecord themselves, rather than an iterable value.
This is an editorial change in the ECMA-262 spec. See:
956e5af
This splits the GetIterator AO into two AOs, to remove some recursion
and to (soon) remove optional parameters.
The refactor of the border painting mainly to handle:
1. Single border with minor border radius.
2. Different border widths and border colors joined situations.
This refactor only apply to solid border.
The main differece is to use Path.fill to paint each border,
not fill_rect anymore. There's a special case need to consider.
The Path.fill will leave shared edge blank between two borders.
To handle this, we decide to combine the borders with same color
to paint together.
Once we've resolved the used flex item width & height, we should allow
percentage flex item sizes to resolve against them instead of forcing
flex items to always treat percentages as auto while doing intrinsic
sizing layout.
Regressed in 8dd489da61.
When specifying either `background-position-x: right` or
`background-position-y: bottom` without an offset value no
EdgeStyleValue was created.
However, the spec says the offset should be optional.
Now, if you do not provide an offset, it creates the EdgeStyleValue
with a default offset of 0 pixels.
I couldn't find a way to hit this function with our current testing
infrastructure, but since it breaks many websites, let's just get a
fix in immediately.
Regressed in 6fecd8cc44.
We do this by piggybacking on FormattingContext helpers instead of
reinventing the wheel in FlexFormattingContext.
This fixes an issue where `min-width: fit-content` (and other
layout-dependent values) were treated as 0 on flex items.
This makes the cookie banners look okay on https://microsoft.com/ :^)
If an inline-block has a percentage height that relies on the auto
height of the containing block, it should always resolve to the
automatic height of the box, regardless of the percentage value. This
change may seem confusing, but it aligns with the behavior of other
engines.
There are two parts to this fix:
- First, StyleProperties::transformations() would previously omit calc()
values entirely when returning the list of transformations. This was
very confusing to StackingContext which then tried to index into the
list based on faulty assumptions. Fix this by emitting calc values.
- Second, StackingContext::get_transformation_matrix() now always calls
resolve() on length-percentages. This takes care of actually resolving
calc() values. If no reference value for percentages is provided, we
default to 0px.
This stops LibWeb from asserting on websites with calc() in transform
values, such as https://qt.io/ :^)
