Previously we would generate the calculation context based on the
current value parsing context. The main problem with this was that
contexts were defined per property by default and had to be overriden
per component value using "special" contexts, which was easy to forget.
We now generate the calculation context per component value in the
relevant `parse_foo_value` methods.
The new failures in `typed_arithmetic.html` are because we no longer
treat percentages as resolving to their property-level type when
computing what the resolved type of a calculation is i.e. when we are
parsing the `<number>` portion of `line-height` we treat percentages as
raw percentages, not lengths. This brings us in line with WebKit but no
longer with Chrome and WPT, I am not sure what the correct behavior is.
This brings a couple of advantages:
- Previously we relied on the caller validating the parsed value was in
bounds after the fact - this was usually fine but there are a couple
of places that it was forgotten (see the tests added in this commit),
requiring the bounds to be passed as arguments makes us consider the
desired range more explicitly.
- In a future commit we will use the passed bounds as the clamping
bounds for computed values, removing the need for the existing
`ValueParsingContext` based method we have at the moment.
- Generating code is easier with this approach
We should only try to parse a dimension-percentage mix in
`parse_css_value_for_properties` if percentages resolve relative to that
dimension, not simply because percentages are allowed in general.
This doesn't currently cause any issues since we check that percentages
are resolved relative to the relevant dimension within the
`parse_foo_percentage_value` functions
This allows us to avoid the ugly hack in
`property_accepted_type_ranges()`.
This also updates the `ValueType` to be `opacity-value` rather than
`opacity` to match the spec.
In a future commit we will be applying clamping to numeric (i.e.
number, percentage, dimension) values which will be done in the
appropriate `Token` getters so accessing the underlying number value
would be a potential footgun
Reconsuming the current token relies on parse_css_value_for_properties()
only consuming a single token, which may be true now but isn't safe to
assume. Wrapping that in a Transaction and reverting it if we need to
run manual parsing, is a much safer pattern.
Ideally we'll get parse_css_value_for_properties() to run the
per-property bespoke parsing code eventually.
Equivalent to using mark() and restore_a_mark() from before, except it
runs even if we return a SyntaxError.
Also removes the deprecated reconsume_current_input_token() call - this
never actually did anything useful anyway.
When a var() fallback value contained trailing whitespace (e.g.
`var(--foo, flex )`), parse_display_value() miscounted the tokens.
The remaining_token_count() check included whitespace tokens, routing
single-keyword values like "flex" to the multi-component path. The
multi-component parser then failed when encountering the trailing
whitespace token.
Fix this by counting only non-whitespace tokens for the single vs
multi-component routing decision, and by skipping whitespace in the
multi-component parsing loop.
The CSS content property's alt text (after `/`) was incorrectly
accepting any content value. Per the CSS Content Module Level 3 spec,
alt text only accepts <string>, <counter>, and <attr()> values. This
change adds type validation in the alt text parsing branch to reject
URLs, quote keywords, images, and other non-alt-text value types.
This fixes 64 subtests in the content-invalid WPT test.
Move grid area rectangle computation and validation from layout to the
CSS parser. Named grid areas that don't form filled-in rectangles now
correctly invalidate the declaration per spec.
The grammar groups this component together meaning that all
sub-components must occur together i.e.
`ordinal slashed-zero small-caps` is valid but
`ordinal small-caps slashed-zero` is not.
We also reuse the logic for parsing from the longhand
`font-variant-numeric` property for simplicity.
The grammar groups this component together meaning that all
sub-components must occur together i.e.
`common-ligatures no-contextual small-caps` is valid but
`common-ligatures small-caps no-contextual` is not.
We also reuse the logic for parsing from the longhand
`font-variant-ligatures` property for simplicity.
The grammar groups this component together meaning that all
sub-components must occur together i.e. `jis78 full-width small-caps` is
valid but `jis78 small-caps full-width` is not.
We also reuse the logic for parsing from the longhand
`font-variant-east-asian` property for simplicity.
Previously we parsed it as `<custom-ident>` in `<counter>` and as a
keyword in `list-style-type`.
The practical effect of this is:
- Spec defined counter style names in `<counter>` are ASCII lowercased
on parse.
- Non spec defined counter style names are allowed in `list-style-type.
We are still to parse the `symbols()` function but this gives us a
better base for that.
Previously we implemented an all encompassing `MathDepthStyleValue`
specifically for the `math-depth` property, this was unnecessary since
we can represent `auto-add` and `<integer>` using existing `StyleValue`
classes.
This brings the values created from parsing in line with those set via
`StylePropertyMap` which allows us to simplify computation
This means we now allow oblique angles when parsing the `font`
shorthand.
This also required us to rename the existing `FontStyle` enum to
`FontStyleKeyword`
As well as being required to implement absolutization this also means we
now bypass a limitation with `LengthPercentage` where we would always
use `SerializationMode::Normal` for the constituent lengths which gains
us some WPT passes
`border-radius` requires a slash between the x/y components, but the
longhands like `border-top-left-radius` don't allow it. This spec
change allows authors to put a slash there for consistency.
Corresponds to:
e938d7d705
This is required after e937f5d - it went unnoticed until now since the
serialization is the same and the relevant code just fell back to it's
own defaults which were the same.
This makes us consistent with how we handle this value within the
`background` shorthand and allows us to remove the special handling in
`StyleComputer::for_each_property_expanding_shorthands`
