Previously, the corner was always set to the top right, except if the
top left turned out to be closest, in which case it would be left
default-initialized instead.
Since we always pass the px value as an argument to resolved(), we can
pass it directly as CSSPixels instead of wrapping it in Length. This
approach allows us to avoid converting to a double, resulting in fewer
precision issues.
This is intended to annotate conversions from unknown floating-point
values to CSSPixels, and make it more obvious the fp value will be
rounded to the nearest fixed-point value.
In general it is not safe to convert any arbitrary floating-point value
to CSSPixels. CSSPixels has a resolution of 0.015625, which for small
values (e.g. scale factors between 0 and 1), can produce bad results
if converted to CSSPixels then scaled back up. In the worst case values
can underflow to zero and produce incorrect results.
The spec allows for these either to be based on the OS, or to be defined
by the browser. Looking at the other browser engines, there's a mix of
the two options. Since we've had issues with using OS colors as
defaults, let's use hard-coded colors for now. Some of these are based
on the definitions in
https://html.spec.whatwg.org/multipage/rendering.html
Reuse the check from IdentifierStyleValue in the CSS Parser, instead of
duplicating it. This might not be the ideal place to put it, but it
works for now.
This allows to partially solve the problem of cyclic dependency between
HTMLImageElement and SharedImageRequest that prevents all image
elements from being deallocated.
These were added when Gfx::Rect was made endpoint exclusive, however,
for this code an offset of ±1 makes no visible difference (but makes the
code look a little confusing).
We now keep the color value as a StyleValue up until we go to paint the
gradient, which makes `currentColor` work, along with any other color
values that can't be immediately converted into a `Gfx::Color` while
parsing.
This is a universal value like `initial` and `inherit` and works by
reverting the current value to whatever we had at the start of the
current cascade origin.
The implementation is somewhat inefficient as we make a copy of all
current values at the start of each origin. I'm sure we can come up with
a way to make this faster eventually.
The CSS box-shadow property takes 2-4 properties that are `<length>`s,
those being:
- offset-x
- offset-y
- blur-radius
- spread-radius
Previously these were resolved directly to concrete Lengths at parse
time, but now they will be parsed as LengthStyleValues and/or
CalculatedStyleValues and be stored that way until styles are later
resolved.
