| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
The apparent size is what `stat` says what we use. The non-apparent size
is the blocks that we actually use on-disk.
|
|
|
|
|
|
|
|
This keeps us from having to duplicate code for each data type we add.
|
|
As noted, we should probably handle calc() parsing as part of parsing
other values. eg, any `<length>` can be a `calc()` that returns a
length, but we currently have to manually handle that everywhere that
doesn't use the `Parser::parse_css_value(ComponentValue)` method.
|
|
|
|
When a `calc()` is resolved, it can only return a Percentage value if
the requested type is Percentage. In all other cases, it returns a
concrete value.
eg, a `calc()` with Lengths and Percentages in will always resolve to a
Length, never a Percentage. This means we can just return Length
directly instead of LengthPercentage, which simplifies things in a few
places.
|
|
|
|
|
|
This is mainly so we can easily read that matrix later, but also has the
benefit of only calculating the matrix once, instead of every time we
paint. :^)
|
|
These are all `m_` prefixed and only used by PaintableBox itself.
|
|
Currently we can't actually paint the result, but at least the maths is
correct. :^)
|
|
Also, made the `reference_length` parameter optional for the lambda that
extracts transform-function parameters, since it is only needed to
resolve `LengthPercentage` parameters.
|
|
|
|
This will be consulted later on in the flex layout algorithm.
|
|
Offsets in this algorithm are relative to the starting position, so it
should be 0 whether its `flex-start` or `flex-end`.
|
|
Make sure that we're painting them at an integer pixel position, to
avoid smearing.
|
|
Before performing intrinsic sizing layout on a box, we now check if its
containing block has automatic size in the relevant axis, and if so,
we fetch the size of the nearest containing block ancestor with a size.
|
|
The spec asks us to do this. It doesn't become relevant until we
implement box-sizing, but might as well do it anyway.
|
|
|
|
|
|
This struct will be needed by more than just the DateTimeFormat object.
Also add an equality operator, which will be needed by NumberFormat.
|
|
This algorithm is to inject spacing around the range separator under
certain conditions. For example, in en-US, the range [3, 5] should be
formatted as "3–5" if unitless, but as "$3 – $5" for currency.
|
|
|
|
This fixes a crash when the error contains '{}', or an invalid format
string.
|
|
|
|
|
|
This skips the new string unicode properties additions, along with \q{}.
|
|
The ECMA262 spec has this as a separate production, and we need it to be
split up for a future commit.
|
|
|
|
|
|
|
|
The Intl mathematical value is much like ECMA-262's mathematical value
in that it is meant to represent an arbitrarily precise number. The Intl
MV further allows positive/negative infinity, negative zero, and NaN.
This implementation is *not* arbitrarily precise. Rather, it is a
replacement for the use of Value within Intl.NumberFormat. The exact
syntax of the Intl MV is still being worked on, but abstracting this
away into its own class will allow hooking in the finalized Intl MV
more easily, and makes implementing Intl.NumberFormat.formatRange
easier.
Note the methods added here are essentially the same as the static
helpers in Intl/NumberFormat.cpp.
|
|
After the Intl MV is implemented, returning a copy of the desired value
here may involve copying non-trivial data. Instead, return an enum to
indicate which decision was made.
|
|
This becomes more of an issue when implementing the Intl mathematical
value, where negative zero is treated as a special enum value. In that
case, we already previously changed the value from -0 to +0 in step 1b.
Entering the branch for step 4 will then set it back to -0.
The math that follows after these steps worked fine with both +0/-0, but
assertions will be reached in the Intl MV implementation.
|
|
Except some minor tweaks, this is a direct copy of Luke's initial
implementation in XMLHttpRequest, now replacing the former.
|
|
This makes two more WPT tests pass here:
http://wpt.live/fetch/api/headers/headers-basic.any.html
|
|
|
|
This automatically fixes an issue where we were accidentally copying
garbage data from beyond the TLS segment as uninitialized data isn't
actually stored inside the image.
|
|
|
|
|
|
Previously, `inline-flex` would blockify to `block` since blockification
didn't take the inner display type into account. This is still not
perfect, but it fixes a lot of situations where inline-level flex
containers would be demoted to regular block containers.
|
|
This is preparation for doing some more work when assigning to these
values.
|
|
This now calls before/after_child_paint() on the parent paintable
of a positioned child. This allows the parent's overflow clipping
to apply to the child.
|
|
Previously, before/after_children_paint() was only called for the
"Foreground" paint phase, this meant the backgrounds and other
features of child nodes of a element with overflow: hidden were
not clipped.
|
|
`min-width: auto` and `min-height: auto` have special behavior on flex
items. We already handled it in many cases but there were two places
where it was incorrectly treated as 0. This fixes that.
|
