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.
The comment mentions that zero is let through, but then immediately
errors out if it sees any number outside quirks mode.
This commit makes that check let zeros through.
Fixes the bug that currently we always consider tracks with percentage
size as ones with "fixed" length even when available size is not
definite. With this change tracks with percentage size when available
size is not definite will be considered as "intrinsic" sized.
...and use it for `margin` and `padding`.
So now, if all four margins are 12px, we output "12px" instead of "12px
12px 12px 12px". This matches the spec's requirement to use the smallest
non-ambiguous representation.
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
