- 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).
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 were introduced in dfe5d00 but only papered over the underlying
issue that we were computing style for element belonging to detached
documents - this underlying fix was implemented in c173a66 so these
fallbacks/guards are no longer needed
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)
Pass AbstractElement around as the target for match_compound_selector()
and match_simple_selector().
This has no effect yet, as we currently handle the pseudo-element at the
top layer and then pass down an AbstractElement without it, but it'll
matter once we stop doing that.
Having 3 different functions named `matches()` that work on different
parts of a selector, all of which take a lot of arguments, makes this
harder to reason about than it needs to be. Rename them like so:
- The public "matches an entire selector" function is still matches()
- matches_compound_selector() for compound selectors
- matches_simple_selector() for simple selectors
...instead of separate Element and PseudoElement arguments.
As noted, AbstractElement's constness is weird currently, but that's a
tangent I don't want to go on right now.
This really represents the final pseudo-element, the one that style
actually applies to. We'll want to know that even once we fully support
having multiple pseudo-elements in a selector.
