Previously, we did an evenodd fill for everything which while for most
SVGs works, it is not correct default (it should be nonzero), and broke
some SVGs. This fixes a few of the icons on https://shopify.com/.
Having one StyleValue for `<number>` and `<integer>` is making user code
more complicated than it needs to be. We know based on the property
being parsed, whether it wants a `<number>` or an `<integer>`, so we
can use separate StyleValue types for these.
This allows us to figure out where a specific CSS property comes from,
which is going to be used in a future commit to uniquely identify
running animations.
Specifically, stop letting NumericStyleValues holding `0` from
pretending to hold a Length. The parser is now smart enough that we
don't have to do this. :^)
Only NumericStyleValue holds integers.
I'm not sure our current distinction between NumericStyleValue holding
an integer or non-integer is useful given it always returns a float.
:thonk:
This implements the stop-opacity, fill-opacity, and stroke-opacity
properties (in CSS). This replaces the existing more ad-hoc
fill-opacity attribute handling.
1. Propagate calc() values from StyleProperties to ComputedValues.
2. Actually resolve calc() values when determining the used flex basis.
This makes the "support" section on https://shopify.com/ show up
correctly as a 2x2 grid (instead of 1x4). :^)
The Display class already supported all specific values, and now they
will be parsed too. The display property now has a special type
DisplayStyleValue.
Rather than passing an increasingly-unwieldy number of font parameters
individually to every function that resolves lengths, let's wrap them
up.
This is frustratingly close to being `Gfx::FontPixelMetrics`, but bitmap
fonts cause issues: We choose the closest font to what the CSS
requests, but that might have a wildly different size than what the
page expects, so we have to fudge the numbers.
No behaviour changes.
This appears to be consistent with other engines, and fixes many pages
where we were misinterpreting super large z-index values as something
else entirely.
At the moment, we can't resolve CSS calc() values without having a
LayoutNode. The new StyleProperties::line_height() overload was trying
to do exactly that, which led to an assertion.
This patch makes `line-height: calc(...)` behave the same as
`line-height: normal` for now and adds a FIXME.
