Although we translate e.g `block` to `block flow` for internal use in
the engine, CSS-DISPLAY-3 tells us to use the short form in
serializations for compatibility reasons.
This adds 9 points to our score on https://html5test.com/ :^)
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. :^)
We're about to stop letting 0 NumericStyleValues pretend to be Lengths,
so this will break. As noted, the flex-basis property accepts
`<length>` not `<number>` so this is actually correct.
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:
Introduces incomplete parsing of grid shorthand property. Only
<grid-template> part of syntax is supported for now but it is enough
to significantly improve rendering of websites that use this shorthand
to define grid :)
If CSS requests a font that we have loaded, but we didn't associate it
with a specific weight and/or slope, let's still use it if it matches
the family name.
This is a hack until we implement proper CSS font selection.
We know what types and identifiers a property can accept, so we can use
that information to only parse things that can be accepted. This solves
some awkward ambiguity problems that we have now or will face in the
future, including:
- Is `0` a number or a length with no unit?
- Is `3.5` a number or a ratio?
- Is `bottom` an identifier, or a custom-ident?
Two CSS Parser methods are introduced here:
`parse_css_value_for_property()` attempts to parse a StyleValue that the
property can accept, skipping any types that it doesn't want.
`parse_css_value_for_properties()` does the same, but takes multiple
PropertyIDs and additionally returns which one the parsed StyleValue is
for. This is intended for parsing shorthands, so you can give it a list
of longhands you haven't yet parsed.
Subsequent commits will actually use these new methods.
We don't yet have generic parsing support for `<filter-value-list>` or
`<paint>`, so listing them here confuses the new StyleValue parsing code
I'm working on. For now, let's skip `<filter-value-list>` since it's
only used in one pkace which manually parses it, and list the parts of
`<paint>` instead which are taken from here:
https://www.w3.org/TR/SVG2/painting.html#SpecifyingPaint
This fixes a plethora of rounding problems on many websites.
In the future, we may want to replace this with fixed-point arithmetic
(bug #18566) for performance (and consistency with other engines),
but in the meantime this makes the web look a bit better. :^)
There's a lot more things that could be converted to doubles, which
would reduce the amount of casting necessary in this patch.
We can do that incrementally, however.
SVG presentation attributes are parsed as CSS values, so we also need to
handle CSS variable expansion when handling them.
This (roughly) matches the behavior of other engines. It's also used on
the web, for example on https://stripe.com/ :^)
If we finish parsing a calculation tree and it still contains
UnparsedCalculationNodes, then it's not valid, and we shouldn't create
a StyleValue from it.
Previously, calling `.right()` on a `Gfx::Rect` would return the last
column's coordinate still inside the rectangle, or `left + width - 1`.
This is called 'endpoint inclusive' and does not make a lot of sense for
`Gfx::Rect<float>` where a rectangle of width 5 at position (0, 0) would
return 4 as its right side. This same problem exists for `.bottom()`.
This changes `Gfx::Rect` to be endpoint exclusive, which gives us the
nice property that `width = right - left` and `height = bottom - top`.
It enables us to treat `Gfx::Rect<int>` and `Gfx::Rect<float>` exactly
the same.
All users of `Gfx::Rect` have been updated accordingly.
