ShadowStyleValue was not absolutizing its color component, which meant
that complex color values like `color-mix()` would retain unresolved
state. This caused a null pointer dereference when `color-mix()` with
omitted percentages was used as a shadow color. We now absolutize the
color component, avoiding this crash.
There was only one place that we weren't passing this where we could
have ASFs so let's just handle that there and explicitly mark the others
as having no ASFs to avoid unnecessary work.
No functional changes
`@function` descriptors are the only ones that support ASFs, while most
descriptors enforce this through their syntaxes implicitly disallowing
ASFs, this wasn't the case for `@property/initial-value`.
We now explictly disallow ASFs unless they are marked as allowed within
`Descriptors.json`.
Everywhere we use this expects us to parse the whole value, either
because we are parsing the value of a declaration (in which case there
will be no semicolons), or because it is called from a JS setter which
takes whole values and semicolons make the value invalid.
Previously we would just ignore everything after a semicolon.
This also allows us to avoid creating a new `Vector` and copying all the
component values
Allow CSS pseudo-element chaining with ::part() so that
selectors like ::part(title)::before can style pseudo-elements
within shadow DOM parts.
Parser changes (SelectorParsing.cpp): The pseudo-element
validation logic now tracks which pseudo-element appears first
and second in a compound selector. When multiple pseudo-elements
are found, the parser permits the selector only if the first is
::part() and the second is NOT ::part(). A maximum of two
pseudo-elements is enforced.
Selector changes (Selector.cpp, Selector.h): The Selector
constructor now stores the last pseudo-element (the styling
target) rather than the first. For ::part(foo)::before, the
selector reports ::before as its target. A new
m_contains_part_pseudo_element flag separately tracks whether
::part() is present for the selector engine.
Fixes 9 WPT tests: 6 in css/selectors/parsing/parse-part.html
for chained selector parsing, and 3 in
css/css-shadow-parts/multiple-scopes.html for correct scoping
of exported, middle-scope, and non-exported part selectors.
When matching ::part(), only consider shadow trees whose host lies in
the same style scope as the rule. Use MatchContext::rule_shadow_root,
which is already set when collecting ::part() rules, as that scope.
For cross-scope rules, accept a candidate shadow root only if its
host's containing_shadow_root() matches the rule's shadow root: the
rule's scope is the document when rule_shadow_root is null, or that
shadow root when the rule comes from its stylesheet.
The one exception is :host::part(): the rule and the part live in the
same shadow root, so its host is outside the rule's scope and the
comparison would never pass. Allow the check to be skipped for this
case by setting MatchContext::for_host_part_matching when the compound
selector contains :host (directly or inside :is(), which is how CSS
nesting resolves &::part() inside a :host rule).
Run that :host pre-scan only when rule_shadow_root is set. Document
rules never use the same-shadow-root exception; scanning would
otherwise set for_host_part_matching whenever :host appears in the
compound and break cross-scope ::part() matching (e.g. multiple-scopes).
Previously the engine walked all ancestor shadow roots without this
cross-scope check.
The main limitation here are that none of the container-query features
are parsed in a meaningful way; they all become `<general-enclosed>`.
Parsing for them will be added as they are implemented.
No parsing yet, just CSSContainerRule and the supporting ContainerQuery
class.
CSSContainerRule is unusual in how it matches, because instead of it
either matching or not matching globally, it instead is matched against
a specific element. But also, some at-rules inside it always apply, as
if they were written outside it. This doesn't fit well with how
CSSConditionRule is implemented, and will likely require some rework
later. For now, `condition_matches()` always returns false, and
`for_each_effective_rule()` is overridden to always process those
global at-rules and nothing else.
When a shorthand like `background` containing `var()` is used in
a `::selection` rule, the shorthand was filtered out by the pseudo-
element property whitelist before variable resolution could occur.
This left PendingSubstitutionStyleValue longhands unresolved,
causing either a crash or incorrect computed values.
Allow unresolved shorthands to bypass the pseudo-element filter so
variable resolution can proceed. After resolution and expansion
into longhands, filter out any that the pseudo-element does not
support.
Fixes#8625.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When parsing declarations within a nested grouping rule, we don't store
these directly, but within a "nested declarations rule", in most cases
this is `CSSNestedDeclarations`, but this isn't always the case e.g.
`@function` rules and others (e.g. @media) within them should instead
use `CSSFunctionDeclarations`
Some at-rules (i.e. `@function`) require us to support custom
descriptors (e.g. `--foo`).
We do this by adding `DescriptorID::Custom` and using a new
`DescriptorNameAndID` class in a bunch of places where we previously
just used `DescriptorID`
Use Skia's SkTextBlob::getIntercepts() to find where glyph outlines
cross the underline/overline band, then split the decoration line into
segments with gaps around those intersections.
Previously we waited until used-value time to apply handling for the
z-index value that we should have applied at declared or computed-value
time, which was papered over by returning the used rather than computed
value as the resolved value. This is no longer required.
This allows us to unmark z-index as requiring a layout node to get
resolved value.
Currently this only applies to the `@property` `syntax` descriptor.
As with custom properties in the previous commit we assumed that any
consumed values were valid but that's not the case.
The definition of syntax in the "css-properties-values-api" spec (which
is used for the `@property/syntax` descriptor) is slightly different
from the definition of `<syntax>` in the "css-values" spec (which we
implement) in that it limits literal idents to exclusively
`<custom-ident>`s (i.e. not CSS-wide keywords or "default").
`<custom-ident>`s are also case-sensitive so that behavior is
implemented for syntax matching here as well
