The definition of syntax in the "css-properties-values-api" spec (which
is used for the `@property/syntax` descriptor) is slightly different
from the definition of `<syntax>` in the "css-values" spec (which we
implement) in that it limits literal idents to exclusively
`<custom-ident>`s (i.e. not CSS-wide keywords or "default").
`<custom-ident>`s are also case-sensitive so that behavior is
implemented for syntax matching here as well
Previously we would consider an alternative syntax child to be a match
as long as parsing produced a value, even if there were trailing tokens
(which would later invalidate it within `parse_with_a_syntax`). This
meant that we wouldn't consider later alternatives which may actually
produce a valid match.
If a custom property is registered, then it may have an initial value
which we should fall back to here.
This is a temporary hack until we cascade our custom properties (see
https://github.com/LadybirdBrowser/ladybird/pull/6608).
Now that we don't remove whitespace when parsing, we don't need to
artificially insert it back in again when serializing. We do now need
to trim leading and trailing whitespace from UnresolvedStyleValues, as
this previously was done as part of the whitespace insertion.
This makes our serialization of UnresolvedStyleValues more correct and
gets us a few WPT passes for each property in the Typed OM tests.
The `transform` property is now parsed based on its JSON data, and
shouldn't behave any differently than before.
This makes `<transform-list>` and `<transform-function>` work in the
`syntax` descriptor for `@property`, and also means we know that
`transform` can accept the `none` keyword. We get a few WPT passes out
of that.
Now we pass all WPT tests in:
`css/css-properties-values-api/at-property-cssom`.
Note: Failing tests were false positives.
Proper handling of inheriting values and detecting computational
independence will be done in another PR.
