Previously we had two implementations for parsing
`<color-interpolation-method>`, one for gradients and one for
`color-mix()` - this commit adds another which will unify the existing
ones in following commits.
This implementation has a couple of advantages over the existing ones:
- It is simpler in that it uses global CSS enums and their helper
functions
- It is spec compliant (unlike the `color-mix()` one which allows
arbitrary idents)
- It parses as a `StyleValue` which will be required once we support
`<custom-color-space>` since that can be an `ident()` which isn't
resolvable at parse time
Many CSS grammars call for us to parse `Foo || Bar` but we don't have a
good way to represent this unless we have a custom style value. Usually
we store the values in a `StyleValueList` but since that can only store
non-null elements we have to manually recheck which elements we have at
which index whenever we use it.
This style value holds a Vector of `RefPtr<StyleValue const>` so that we
can represent null values and know what values are at what index without
manually rechecking.
Previously we parsed it as `<custom-ident>` in `<counter>` and as a
keyword in `list-style-type`.
The practical effect of this is:
- Spec defined counter style names in `<counter>` are ASCII lowercased
on parse.
- Non spec defined counter style names are allowed in `list-style-type.
We are still to parse the `symbols()` function but this gives us a
better base for that.
I originally wanted to move this to prevent a circular dependency, in a
commit that I'm probably not submitting any more. But also, there's
nothing about this type that is CSS or LibWeb-specific, so let's put
this in AK.
Previously we implemented an all encompassing `MathDepthStyleValue`
specifically for the `math-depth` property, this was unnecessary since
we can represent `auto-add` and `<integer>` using existing `StyleValue`
classes.
This brings the values created from parsing in line with those set via
`StylePropertyMap` which allows us to simplify computation
Previously, some StyleValues created a large number of intermediate
strings during serialization. Passing a StringBUilder into the
serialization function allows us to avoid a large number of these
unnecessary allocations.
Previously this was implemented inline within the parsing of
`{repeating}-radial-gradient()` functions but it will also be useful for
`circle()` and `ellipse()`.
We now support the CSS Images Module Level 4 additions to the
`<radial-size>` syntax, namely:
- `<length-percentage>` rather than just `<length>` for circles.
- Distinct `<radial-extent>` values for horizontal and vertical for
ellipses.
- Mixing of `<radial-extent>` and `<length-percentage>` values for
ellipses.
The regressions are due to WPT not being updated to expect the first of
these additions.
CSS Text 3 gives `text-indent` a couple of optional keywords to control
which lines are affected. This commit parses them, but doesn't yet do
anything with them.
This algorithm is used by Typed-OM for producing a list of internal
style values from a single one, for properties that take a list. We
will probably need to implement this for more StyleValues later.
We don't need all this specific logic for parsing the `transition`
property - we also now maintain `none` as such until use time which
gains us a couple extra tests
Since we now have access to the `AbstractElement` through the
`ComputationContext` we can just set the flag that this element relies
on tree counting functions directly, no need to pass this struct around.
Adds support for `sibling-index()` and `sibling-count()` when parsing
`<number>` and `<integer>`. This is achieved by a new
`TreeCountingFunctionStyleValue` class which is converted within
`absolutized` to `NumberStyleValue` and `IntegerStyleValue` respectively
There are still a few kinks to work out in order to support these
everywhere, namely:
- There are some `StyleValue`s which aren't absolutized (i.e. those
which are stored within another `StyleValue` without an
`absolutize()` method.
- We don't have a way to represent this new `StyleValue` within
`{Number,Integer}OrCalculated`. This would be fixed if we were to
instead just use the `StyleValue` classes until style computation at
which time they would be absolutized into their respective
primitives (double, i64, etc) bypassing the need for *OrCalculated
entirely.
This struct will in the future hold information other than a length
resolution context (e.g. context for tree counting functions) and a
single struct is easier to work with than multiple parameters.
This introduces the `TextUnderlinePositionStyleValue` class, it is
possible to represent `text-underline-position` as a `StyleValueList`
but would have required ugly workarounds for either serialization or in
`ComputedProperties::text_underline_position`
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.
CSSUnitValue is a typed-om type which we will implement separately in
the future. However, it still seems useful to give our dimension values
a base class. (Maybe they could be templated in the future?) So instead
of deleting it entirely, rename it to DimensionStyleValue and make its
API match our style better.
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. 😅
2025-08-08 15:19:03 +01:00
Renamed from Libraries/LibWeb/CSS/CSSStyleValue.h (Browse further)
