Previously if we encountered a keyword other than `fill` when parsing
`<border-image-slice` we would return a nullptr.
This could cause issues when we parse `<border-image-slice>` as part of
parsing `border-image`, for example `border-image: 100% none` would fail
as we would try parse `none` as part of the `<border-image-slice>`
instead of `<border-image-source>`.
This change makes it so that we don't consume the token and leave it to
be parsed as part of the next section of the grammar.
Custom properties are required to produce a computed value just like
regular properties. The computed value is defined in the spec as
"specified value with variables substituted, or the guaranteed-invalid
value", though in reality all arbitrary substitution functions should be
substituted, not just `var()`.
To support this, we parse the CSS-wide keywords normally in custom
properties, instead of ignoring them. We don't yet handle all of them
properly, and because that will require us to cascade them like regular
properties. This is just enough to prevent regressions when implementing
ASFs.
Our output in this new test is not quite correct, because of the awkward
way we handle whitespace in property values - so it has 3 spaces in the
middle instead of 1, until that's fixed.
It's possible this computed-value production should go in
cascade_custom_properties(), but I had issues with that. Hopefully once
we start cascading custom properties properly, it'll be clearer how
this should all work.
No functional changes. The main difference is renaming the cursor enum
to match the spec term `<cursor-predefined>`, which is a bit more
verbose but clearer in meaning.
Corresponds to 1a57a4025c
This brings parsing of grid-row-* and grid-column-* properties (and
their associated shorthands) more inline with spec.
Changes:
- Only set omitted properties for combined-value shorthands (e.g.
`grid-row: a` rather than `grid-row: a / b`) if the single value is
`<custom-ident>`.
- `[ [ <integer [-∞,-1]> | <integer [1,∞]> ] && <custom-ident>? ]`:
- Properly resolve `calc`s for `<integer>` that rely on compute-time
information.
- `[ span && [ <integer [1,∞]> || <custom-ident> ] ]`
- Allow `calc`s for `<integer>`
- Allow `<custom-ident>`
There is still work to be done to properly use these parsed values.
Gains us 46 WPT tests.
Reimplements `grid`, `grid-template`, `grid-template-rows`, and
`grid-template-columns` in a way that uses a separate function for each
grammar rule defined in the specification. This change results in many
additional passing tests from the already imported WPT suite. Most of
the remaining test failures are related to incorrect serialization of
grid properties.
The "longhands" array is populated in the code generator to avoid the
overhead of manually maintaining the list in Properties.json
There is one subtest that still fails in
'cssstyledeclaration-csstext-all-shorthand', this is related to
us not maintaining the relative order of CSS declarations for custom vs
non-custom properties.
This exposed a few bugs which caused the following tests to behave
incorrectly:
- `tab-size-text-wrap.html`: This previously relied on a bug where we
incorrectly treated `white-space: pre` as allowing text wrapping. The
fix here is to implement the text-wrap CSS shorthand property.
- `execCommand-preserveWhitespace.html`: We don't correctly serialize
shorthand properties. This is covered by an existing FIXME in
`CSSStyleProperties::serialized()`
- `white-space-shorthand.html`: The last 5 subtests here fail as we
don't correctly handle shorthand properties in
`CSSStyleProperties::remove_property()`. This is covered by an
existing FIXME in said function.
We don't want to reset the values of `font-variant-*` here, as that will
override whatever our parsed font-variant-css2 was, so stop doing that.
Also, font-stretch is mentioned in the spec, but it's a legacy name
alias for font-width, so we don't need to do anything for it.
Gets us 319 WPT passes!
These are not the same as parsing their properties, but are limited to a
small set of keywords each. The easiest way to handle these is parsing
them directly here.
Update some comments while I'm here.
