sort_matching_rules() was calling Selector::specificity() inside the
sort comparator. MatchingRule already caches the specificity value
at rule insertion time, so use that directly instead.
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.
When the two component percentages of color-mix() sum
to less than 100%, the remainder is used as an alpha multiplier applied
to the interpolated result's alpha. Previously, this was only applied
in the runtime `to_color()` path, not when computing the absolutized
value used by `getComputedStyle()`.
Switch both paths to use `perform_color_interpolation()` directly so the
alpha multiplier can be applied to the interpolated components before
they are converted to a style value.
- These should be Percentage tokens, not Dimensions.
- The `unit_name` is "percent", so the serialization also came out wrong
as e.g. `10percent` instead of `10%`.
The counter style used for an element (in either the `content` or
`list-style-type`) may change despite the computed values of properties
on that element remaining the same (e.g. if a new rule is inserted with
higher cascade precedence).
This was a pretty straightforward change of storing registered counter
styles on the relevant `StyleScope`s and resolving by following the
process to dereference a global tree-scoped name, the only things of
note are:
- We only define predefined counter styles (e.g. decimal) on the
document's scope (since otherwise overrides in outer scopes would
themselves be overriden).
- When registering counter styles we don't have the full list of
extendable styles so we defer fallback to "decimal" for undefined
styles until `CounterStyle::from_counter_style_definition`.
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.
...instead of iterating through its components. This lets us initialize
the MatchingRule directly, now using designated initializers to
distinguish between the different bool fields.
No behaviour changes.
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).
