...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.
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.
Stop rebuilding the counter style cache from every style update.
That made unrelated restyles pay the full counter-style cost even when
no relevant stylesheet state had changed.
Dirty the cache when stylesheet rule caches are invalidated and rebuild
it on the first counter-style lookup instead. Also make cold cache
rebuilds include user stylesheets.
Add regression tests covering insertRule() and replaceSync() updates
that should make newly defined counter styles take effect.
Constructed stylesheets updated their rule lists, but adopted documents
and shadow roots were not restyled when replace(), replaceSync(),
or disabled-state changes modified the sheet. That left several CSSOM
tests passing stale computed styles.
Invalidate stylesheet owners after those updates so adopted sheets
recompute promptly. Also set replace()-produced rules' parent
stylesheet so non-import rules keep their stylesheet context.
The imported baseURL test assumes a tuple origin, so move it to the
HTTP fixture now that replaceSync() actually triggers a restyle.
Previously, FontFace objects created via the JS and added to
`document.fonts` were stored in the FontFaceSet but never participated
in font matching during style resolution. We now store both
CSS-connected and JS-created font faces in a unified map on
`FontComputer`, keyed by family name, and include them all as
candidates in the font matching algorithm.
Previously, `FontComputer` used two key types for its font map: a
non-owning `FontFaceKey` for lookups and an owning `OwnFontFaceKey` for
storage. This change replaces both with a single FontFaceKey that owns
its FlyString.
We maintain a registry of elements with an anchor-name so once they are
referenced for anchor positioning, we can find them with an O(1) lookup
instead of traversing the entire DOM tree.
This correctly rejects invalid trailing tokens from `anchor()` fallback
values. Also introduces discard_whitespace() to take care of any
whitespace between the fallback value and the closing parenthesis.
We now ignore all animation properties from `css-animations-1` declared
within keyframes, except `animation-timing-function`, which is treated
specially.
When a `@keyframes` rule contains `animation-timing-function` with a
`var()`, we cannot eagerly resolve it to an `EasingFunction` at rule
cache build time because there is no element context available. We now
store the unresolved `StyleValue` and defer resolution to
`collect_animation_into()`, where the animated element's custom
properties can be used to substitute the variable. Previously, an
`animation-timing-function` with a `var()` in a `@keyframe` would cause
a crash.
