The @keyframes parser was storing the keyframes name via
Token::to_string(), which keeps a string token in its quoted,
serialized form. That meant @keyframes "foo" was stored as
"\"foo\"" while animation-name: "foo" resolved to "foo",
and the two never matched.
Store the unquoted string or identifier value so the @keyframes name
and the animation-name reference compare on the same string.
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
In a future commit we will use the allowed literal values as the bounds
for calculated values rather than the existing `ValueParsingContext`
based system. Since the computed bounds are different from the allowed
literal values here we need to handle clamping them manually.
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.
This matches the behavior of other browsers. We did the equivalent
change for <integer> in b86377b
We continue to store these as doubles for the extra precision.
This brings us in line with the other numeric types (percentage and
dimension) and allows us to test the clamping behavior that will be
added in a future commit.
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
Introduce a descriptor table keyed by `ColorType` that encodes
per-space metadata: channel kind, percent reference value, clamp
bounds, function name and serialization behavior.
This descriptor table is then used so that a single class can back
every CSS color type. Resolution, serialization, and absolutization
are driven by the descriptor.
This is sometimes the best tool for the job. To try and make it less of
a footgun that peek_token() is identical to next_token(), make the
offset required, and note the shared behaviour. Also move them
together, and make the internal code match.
The main change is that we now wait to consume the token until we know
we want it, instead of consuming it and then later putting it back.
While I was here, I spec-commented some parts and updated the URL.
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.
This relied on input_since() being called after
consume_an_ident_sequence(), which is not at all guaranteed. GCC
evidently evaluates the arguments in the opposite order.
This caused AtKeyword tokens to have their original source text be `@`
instead of the full `@whatever`, which apparently has no consequences
in our current code, but does mess up the debug output introduced in
the following commit.
These are only used at used value time (since we store as `StyleValue`s
before) by which time we resolve all percentages except for layout
relative length percentages.
Apart from making the code a bit easier to follow, we'll need to
distinguish between the two in order to insert a pseudo-element
combinator in front of pseudo-elements (including the single-colon
legacy ones).
next_is_pseudo_element() is its own function because it'll be needed in
a couple of other places, again to support pseudo-element combinators.
This spec note reads to me as explicitly disallowing combining
`<length>` and `<flex>` (i.e. `calc(1px + 1fr)`). This behavior is
already implemented (as it is for all other combination of units i.e.
`<length>` and `<time>`).
This simplifies handling (particularly around absolutization and
interpolation) and allows us to support calculated flex values (which
will come in a later commit).
This allows places that want to parse a lone `<compound-selector>` to do
so without also implicitly parsing a combinator before it.
Also add error reporting in a bunch of places that previously failed
silently.
This introduces two new top-level `ValueParsingContext`s,
`OnScreenCanvasContextFontValue` and `CanvasContextGenericValue`, while
these are handled the same for now, there is a distinction is whether or
not they allow tree counting functions (which will come in a later
commit)
The HTML sizes algorithm does not use full media queries. It evaluates
a restricted media-condition grammar and then parses the selected
source size value as a length.
Teach the parser to follow that split more closely: treat sizes
conditions as two-valued booleans, validate MQ5 <general-enclosed>
contents more strictly, accept calc(0) for media feature values, and
reject only source-size math results that are negative or non-finite.
The imported sizes parsing tests then progress from 140/171 to
171/171 in all four cases.
