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.
It's probably not in 1:1 as spec says, as it wants us to first upscale
the image to the nearest integer and then downscale it bilinearly.
But this mode still falls into the general description of the value:
> The image is scaled in a way that preserves the pixelated nature of
> the original as much as possible, but allows minor smoothing instead
> of awkward distortion when necessary.
Also, this way we don't have to allocate the memory just for the integer
scale. :^) :^)
Every StyleValue type now has its own `equals()` method, rather than
relying on the default "compare the to_string() output" method, which
has now been removed. This logic is still used by UnresolvedSV and
CalculatedSV, because it's probably the best option for them unless
performance becomes a real issue.
Also took this opportunity to move all the `equals()` implementations
into the .cpp file, which may or may not actually help with compile
times but StyleValue.h is huge and included everywhere, so it can't
hurt.
"Component value" is the term used in the spec, and it doesn't conflict
with any other types, so let's use the shorter name. :^)
Also, this doesn't need to be friends with the Parser any more.
CSS Values and Units Module Level 5 defines attr as:
`attr(<q-name> <attr-type>?, <declaration-value>?)`
This implementation does not contain support for the type argument,
effectively supporting `attr(<q-name>, <declaration-value>?)`
The `text-shadow` property is almost identical to `box-shadow`:
> Values are interpreted as for box-shadow [CSS-BACKGROUNDS-3].
> (But note that the inset keyword are not allowed.)
So, let's use the same data structures and parsing code for both. :^)
This patch adds support for "crisp-edges", "high-quality" and "smooth"
for the CSS image-rendering property.
"crisp-edges" maps to nearest-neighbor scaling for <canvas> and <img>
elements, while "high-quality" and "smooth" both use bilinear blending.
Instead of awkwardly visiting and mutating lengths inside StyleValues,
we now simply create a new StyleValue instead.
This fixes an issue where inherited relative lengths could get
absolutized using a parent as reference, and then not having the correct
values when used in a child context.
For now, we only understand `none`, `normal`, `<image>` and `<string>`.
The various other functions and identifiers can be added later.
We can *almost* use a StyleValueList for this, except it's divided into
two parts - the content, and the optional "alt text". So, I've added a
new StyleValue for it.
Depending on the type of the calc() expression, the percentage_basis has
to be the same dimension type. Several places were already passing `
{}` for this, so let's make that an empty Variant instead of an
undefined Length. :^)
None of these require any outside metrics, which is nice! I believe the
Values-4 spec would have us simplify them down into a single value at
parse time, but that's a yak for another day.
The previous static functions are now methods of their respective
CalcFoo structs, but the logic has not changed, only that they work
with CalculationResults instead of converting everything to floats.
calc() sub-expressions can return a variety of different types, which
then can be combined using the basic arithmetic operators. This class
should make that easier to deal with, instead of having to handle all
the possible combinations at each call site. :^)
We take the Layout::Node as a pointer not a reference, since later we'll
need to call these functions when resolving to `<number>` or `<integer>`
which don't use those, and we don't want to force users to pass them in
unnecessarily.
See https://www.w3.org/TR/css-values-3/#calc-type-checking
If the sub-expressions' types are incompatible, we discard the calc() as
invalid.
Had to do some minor rearranging/renaming of the Calc structs to make
the `resolve_foo_type()` templates work too.
