When no better reification form is available, we produce an opaque
CSSStyleValue with a serialized value. For starters, this will be the
only way to reify, and then we'll add others later.
This reverts 0e3487b9ab.
Back when I made that change, I thought we could make our StyleValue
classes match the typed-om definitions directly. However, they have
different requirements. Typed-om types need to be mutable and GCed,
whereas StyleValues are immutable and ideally wouldn't require a JS VM.
While I was already making such a cataclysmic change, I've moved it into
the StyleValues directory, because it *not* being there has bothered me
for a long time. 😅
These will be used for the mask-repeat property as well in an upcoming
commit, hence the more generic names. Also, this more closely matches
the names used in the spec.
Using a generic context argument will allow us to resolve colors in
places where we have all the required information but not in the form of
a layout node as was expected previously.
This parses `anchor-size(..)` functions in CSS, but does not yet result
in a useful `Size`: we need style & layout interleaving similar to
container queries for this, since the resulting value depends on layout
results.
Not supported yet: `anchor-size()` appearing inside a `calc()` node.
Adds 4280 WPT subtest passes in `css/css-anchor-position`.
A couple of arbitrary substitution functions require us to get or
produce some style value, and then substitute its ComponentValues into
the original ComponentValue list. So this commit gives CSSStyleValue a
tokenize() method that does so.
Apart from a couple of unusual cases like the guaranteed-invalid value,
style values can all be converted into ComponentValues by serializing
them as a string, and then parsing that as a list of component values.
That feels unnecessarily inefficient in most cases though, so I've
implemented faster overrides for a lot of the basic style value
classes, but left that serialize-and-reparse method as the fallback.
`CSSColorValue`s which have unresolved `calc` components should be able
to be resolved. Previously we would always resolve them but with
incorrect values.
This is useful as we will now be able to now whether we should serialize
colors in their normalized form or not.
Slight regression in that we now serialize (RGB, HSL and HWB) colors
with components that rely on compute-time information as an empty
string, but that will be fixed in the next commit.
The CSS `fetch_foo()` functions resolve the URL relative to the
CSSStyleSheet if one is provided. So, style values that do so need to
know what CSSStyleSheet they are part of so that, for example, `url
(foo.png)` is loaded relative to the style sheet's URL instead of the
document's one.
That all works without this change because we currently absolutize URLs
during parsing, but we're in the process of stopping that.
This commit adds the infrastructure for telling style values what their
CSSStyleSheet is.
Having this hidden away in ImageStyleValue meant that
CSSStyleProperties (and anyone else who holds style values) had to know
exactly which types need visiting. This is a footgun waiting to happen,
so make this a virtual method on CSSStyleValue instead.
A cursor is an image, with an optional x,y hotspot.
We know that a CursorStyleValue's bitmap never needs to change size, so
we create the ShareableBitmap once and then cache it, so that we don't
have to repeatedly create an FD for it or do the work of painting.
To avoid repainting that bitmap, we cache the values that were used to
create it - what currentColor is and its length resolution context -
and only repaint when those change.
Before this change, we only parsed fit-content as a standalone keyword,
but CSS-SIZING-3 added it as a function as well. I don't know of
anything else in CSS that is overloaded like this, so it ends up looking
a little awkward in the implementation.
Note that a lot of code had already been prepped for fit-content values
to have an argument, we just weren't parsing it.
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`.
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.
