We previously had PropertyOwningCSSStyleDeclaration and
ResolvedCSSStyleDeclaration, representing the current style properties
and resolved style respectively. Both of these were the
CSSStyleDeclaration type in the CSSOM. (We also had
ElementInlineCSSStyleDeclaration but I removed that in a previous
commit.)
In the meantime, the spec has changed so that these should now be a new
CSSStyleProperties type in the CSSOM. Also, we need to subclass
CSSStyleDeclaration for things like CSSFontFaceRule's list of
descriptors, which means it wouldn't hold style properties.
So, this commit does the fairly messy work of combining these two types
into a new CSSStyleProperties class. A lot of what previously was done
as separate methods in the two classes, now follows the spec steps of
"if the readonly flag is set, do X" instead, which is hopefully easier
to follow too.
There is still some functionality in CSSStyleDeclaration that belongs in
CSSStyleProperties, but I'll do that next. To avoid a huge diff for
"CSSStyleDeclaration-all-supported-properties-and-default-values.txt"
both here and in the following commit, we don't apply the (currently
empty) CSSStyleProperties prototype yet.
Previously, parse_css_style_attribute() would parse the string, extract
the properties, add them to a newly-created
ElementInlineCSSStyleDeclarations, and then user code would take the
properties back out of it again and throw it away. Instead, just return
the list of properties, and the caller can create an EICSD if it needs
one.
A couple of fixes here:
- Parse a `<complex-selector>` instead of a `<selector-list>`
- Don't match if any unknown `::-webkit-*` pseudo-elements are found
CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place
of the bespoke grammar that previously existed for `@media` and
`@supports` queries. This commit implements some BooleanExpression
types to represent the nodes in a `<boolean-expr[]>`, and reimplements
`@media` and `@supports` queries using this.
The one part of this implementation I'm not convinced on is that the
`evaluate()` methods take a `HTML::Window*`. This is a compromise
because `@media` requires a Window, and `@supports` does not require
anything at all. As more users of `<boolean-expr[]>` get implemented in
the future, it will become clear if this is sufficient, or if we need
to do something smarter.
As a bonus, this actually improves our serialization of media queries!
Instead of parsing the parts of a `@supports` query, then only
evaluating them when constructing the Supports itself, we can instead
evaluate them as we parse them. This simplifies things as we no longer
need to pass a Realm around, and don't have to re-parse the conditions
again with a new Parser instance.
This is not really a context, but more of a set of parameters for
creating a Parser. So, treat it as such: Rename it to ParsingParams,
and store its values and methods directly in the Parser instead of
keeping the ParsingContext around.
This has a nice side-effect of not including DOM/Document.h everywhere
that needs a Parser.
A few of these are only ever called with T=Token, so let's simplify them
a bit.
As a drive-by change: Also correct the "unnecessairy" typos and use
discard_a_token().
This file has been a pain to edit for a while, even with the previous
splits. So, I've divided it up into 3 parts:
- Parser.cpp has the "base" code. It's the algorithms and entry-points
defined in the Syntax spec.
- ValueParsing.cpp contains code for parsing single values, such as a
length, or a color, or a calculation.
- PropertyParsing.cpp contains code for parsing an entire property's
value. A few of these sit in a grey area between being a property's
value and a value in their own right, but the rule I've used is "is
this useful outside of a single property and its shorthands?"
This only moves code, with as few modifications as possible to make that
work. I did add explicit instantiations for the template implementations
as part of this, which revealed a few that are actually only compatible
with a single type, so I'll clear those up in a subsequent commit.
If a calculation was simplified down to a single numeric node, then most
of the time we can instead return a regular StyleValue, for example
`calc(2px + 3px)` would be simplified down to a `5px` LengthStyleValue.
This means that parse_calculated_value() can't return a
CalculatedStyleValue directly, and its callers all have to handle
non-calculated values as well as calculated ones.
This simplification is reflected in the new test results. Serialization
is not yet correct in all cases but we're closer than we were. :^)
Calc simplification eventually produces a single style-value as its
output. This extra context data will let us know whether a calculated
number should be treated as a `<number>` or an `<integer>`, so that for
example, `z-index: 12` and `z-index: calc(12)` both produce an
`IntegerStyleValue` containing 12.
Calc simplification (which I'm working towards) involves repeatedly
deriving a new calculation tree from an existing one, and in many
cases, either the whole result or a portion of it will be identical to
that of the original. Using RefPtr lets us avoid making unnecessary
copies. As a bonus it will also make it easier to return either `this`
or a new node.
In future we could also cache commonly-used nodes, similar to how we do
so for 1px and 0px LengthStyleValues and various keywords.
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
We have an optimization that allows us to invalidate only the style of
the element itself and mark descendants for inherited properties update
when the "style" attribute changes (unless there are any CSS rules that
use the "style" attribute, then we also invalidate all descendants that
might be affected by those rules). This optimization was not taking into
account that when the inline style has custom properties, we also need
to invalidate all descendants whose style might be affected by them.
This change fixes this bug by saving a flag in Element that indicates
whether its style depends on any custom properties and then invalidating
all descendants with this flag set when the "style" attribute changes.
Unlike font relative lengths invalidation, for elements that depend on
custom properties, we need to actually recompute the style, instead of
individual properties, because values without expanded custom properties
are gone after cascading, and it has to be done again.
The test added for this change is a version of an existing test we had
restructured such that it doesn't trigger aggressive style invalidation
caused by DOM structured changes until the last moment when test results
are printed.
Same again, although rotation is more complicated: `rotate`
is "equivalent to" multiple different transform function depending on
its arguments. So we can parse as one of those instead of the full
`rotate3d()`, but then need to handle this when serializing.
The only ways this varies from the `scale()` function is with parsing
and serialization. Parsing stays separate, and serialization is done by
telling `TransformationStyleValue` which property it is, and overriding
its normal `to_string()` code for properties other than `transform`.
`current_property_id()` is insufficient to determine if a quirk is
allowed. For example, unitless lengths are allowed in certain
properties, but NOT if they are inside a calc() or other function. It's
also incorrect when we are parsing a longhand inside a shorthand. So
instead, replace that with a stack of value-parsing contexts. For now,
this is either properties or CSS functions, but in future can be
expanded to include media features and other places.
This lets us disallow quirks inside functions, like we're supposed to.
It also lays the groundwork for being able to more easily determine
what type a percentage inside a calculation should become, as this is
based on the same stack of contexts.
Rather than partly-converting number, dimension, and ident tokens at the
start of parsing a calculation, and then later finishing it off, we can
just do the whole step in convert_to_calculation_node(). This is a
little less code, but mainly means we are left with only a single use
of the Dimension type in the codebase, so that can be removed soon.
Various places in the spec allow for `<number> | <percentage>`, but this
is either/or, and they are not allowed to be combined like dimensions
and percentages are. (For example, `calc(12 + 50%)` is never valid.)
User code generally doesn't need to care about this distinction, but it
does now need to check if a calculation resolves to a number, or to a
percentage, instead of a single call.
The existing parse_number_percentage[_value]() methods have been kept
for simplicity, but updated to check for number/percentage separately.
An upcoming change requires that we can determine which property we are
parsing before we parse the value. That's the opposite of what this
code previously did, which was to parse a generic dimension or calc()
and then figure out what property would accept it.
When we know what kind of dimension we want, it's awkward to attempt to
parse any dimension type, including quirks that only affect lengths, to
then throw it away unless it's the type we wanted in the first place.
Additionally, move the unitless angle/length behavior for SVG attributes
into these methods, where it belongs.
Instead, only try to parse the type of dimension we want. This is
currently more code, but some could be factored together later.
When we originally implemented calc(), the result of a calculation was
guaranteed to be a single CSS type like a Length or Angle. However, CSS
Values 4 now allows more complex type arithmetic, which is represented
by the CSSNumericType class. Using that directly makes us more correct,
and allows us to remove a large amount of now ad-hoc code.
Unfortunately this is a large commit but the changes it makes are
interconnected enough that doing one at a time causes test
regressions.
In no particular order:
- Update our "determine the type of a calculation" code to match the
newest spec, which sets percent hints in a couple more cases. (One of
these we're skipping for now, I think it fails because of the FIXMEs
in CSSNumericType::matches_foo().)
- Make the generated math-function-parsing code aware of the difference
between arguments being the same type, and being "consistent" types,
for each function. Otherwise those extra percent hints would cause
them to fail validation incorrectly.
- Use the CSSNumericType as the type for the CalculationResult.
- Calculate and assign each math function's type in its constructor,
instead of calculating it repeatedly on-demand.
The `CalculationNode::resolved_type()` method is now entirely unused and
has been removed.
This reverts commit 76daba3069.
We're going to need separate types for the JS-exposed style values, so
it doesn't make sense for us to match their names with our internal
types.
CSS filters work similarly to canvas filters, so it makes sense to have
Gfx::Filter that can be used by both libraries in an analogous way
as Gfx::Color.
Previously we created a tree of CalculationNodes with dummy
UnparsedCalculationNode children, and then swapped those with the real
children. This matched the spec closely but had the unfortunate
downside that CalculationNodes couldn't be immutable, and couldn't know
their properties at construct-time. UnparsedCalculationNode is also a
footgun, as if it gets left in the tree accidentally we would VERIFY().
So instead, let's parse the calc() tree into an intermediate format, and
then convert each node in that tree, depth-first, into its
corresponding CalculationNode. This means each CalculationNode knows
what its children are when it is constructed, and they never change.
Apart from deleting UnparsedCalculationNode, we can also get rid of the
for_each_child_node() method that was only used by this "replace the
children" code.
When the "Consume a component value from input, and do nothing."
step in `Parser::consume_the_remnants_of_a_bad_declaration` was
executed, it would allocate a `ComponentValue` that was then
immediately discarded.
Add explicitly `{}_and_do_nothing` functions for this case that never
allocate a `ComponentValue` in the first place.
Also remove a `(Token)` cast, which was unnecessarily copying a `Token`
as well.
