The main change here is that we now properly absolutize values which
means we now support `random()` and `sibling-{count,index}()`
We are also more consistent with how we handle computation for the other
font properties
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
This means we now allow oblique angles when parsing the `font`
shorthand.
This also required us to rename the existing `FontStyle` enum to
`FontStyleKeyword`
Add ElementResizeAction to Page (maybe there's a better place). It's
just a mousemove delegate that updates styles on the target element.
Add ChromeMetrics for zoom-invariant chrome like scrollbar thumb
thickness, resize gripper size, paddings, etc. It's not user-stylable
but separates basic concerns in a way that a visually gifted
designer unlike myself can adjust to taste.
These values are pre-divided by zoom factor so that PaintableBox can
continue using device_pixels_per_css_pixel calls as normal.
The adjusted metrics are computed on demand from Page multiple times
per paint cycle, which is not ideal but avoids lifetime management and
atomics. Maybe someone with more surety about the painting flow control
can improve this, but it won't be a huge win. If profiling shows
this slowing paints, then Ladybird is in good shape.
Update PaintableBox to draw the resize gripper and deconflict
the scrollbars. Set apropriate cursors for scrollbars and gripper in
mousemove. We override EventHandler's cursor handling because nothing
should ever come between a man and his resize gripper.
Chrome metrics use the CSSPixels class. This is good because it's
broadly compatible but bad because they're actually different units
when zoom is not 1.0. If that's a problem, we could make a new type
or just use double.
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.
The color stop members were RefPtr which compares by pointer identity.
This caused false positives in style invalidation when the same gradient
color values were recomputed as different objects.
The x and y members were RefPtr which compares by pointer identity.
This caused false positives in style invalidation when the same values
were recomputed as different objects.
The member type was NonnullRefPtr which compares by pointer identity.
This caused false positives in style invalidation when the same values
were recomputed as different objects.
The member types were NonnullRefPtr which compares by pointer identity.
This caused false positives in style invalidation when the same color
values were recomputed as different objects.
`EdgeStyleValues` which consist of an offset of a `calc()`s which
resolves to 50% should be considered "centered" for
`SerializationMode::ResolvedValue` for the purpose of omitting the
position value from gradient serialization.
As well as being required to implement absolutization this also means we
now bypass a limitation with `LengthPercentage` where we would always
use `SerializationMode::Normal` for the constituent lengths which gains
us some WPT passes
The Transformation class wasn't really accomplishing anything. It still
had to store StyleValues, so it was basically the same as
TransformationStyleValue, with extra steps to convert from one to the
other. So... let's just use TransformationStyleValue instead!
Apart from moving code around, the behavior has changed a bit. We now
actually acknowledge unresolvable parameters and return an error when
we try to produce a matrix from them. Previously we just skipped over
them, which was pretty wrong. This gets us an extra pass in the
typed-om test.
We also get some slightly different results with our transform
serialization, because we're not converting to CSSPixels and back.
Some transform-functions are not reifiable as a CSSTransformComponent,
for example a matrix() with sibling-index() in it. In that case, rather
than crashing, fall back to the basic CSSStyleValue reification.
The crash doesn't happen yet, but would with the following commit's
changes. Currently, Transformation::to_matrix() completely ignores
unsupported argument types, but in the next commit that's replaced with
TransformationStyleValue::to_matrix(), which attempts to handle them
properly.
This is equivalent to the existing `PositionStyleValue::create_center`
but returns the value expected after computation has been completed
(i.e. `50% 50%` rather than `center center`)
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.
This also allows us to remove the path generation and interpolation
handling for `rect()` and `xywh()` since that occurs after computation
Regressions in clip-path-interpolation-xywh.html are due to improper
simplification of length-percentage mixes where the length is 0px.
Storing these within `LengthPercentage`, `LengthBox`, and `Variant`
over-complicated things.
We also now use the correct `SerializationMode` when serializing `xywh`
and `rect`
This lets us not care about non-absolute Length units when resolving
gradient data, as they'll already have been converted to px.
We can also use Angle::from_style_value() safely on absolutized angles,
which reduces some boilerplate code.
A few things fall out of this:
- We no longer need to templatize our color-stop list types.
- A bit more code is required to resolve gradient data.
This results in a slightly different rendering for a couple of the test
gradients, with a larger difference between macOS and Linux. I've
expanded the fuzziness factor to cover for it.
This works by generating random values using XorShift128PlusRNG at
compute time and then caching them on the document using the relevant
random-caching-key
We know that longhand values are always `StyleValueList`s
Introduces a new fail in the `view-timeline-shorthand.html` WPT test
but this is because the test is incorrect and we now correctly don't
contract when `view-timeline-inset` has dissimilar cardinality. See
web-platform-tests/wpt#56181
The remaining failing tests in view-timeline-shorthand.html are due to
either:
a) incorrect tests, see web-platform-tests/wpt#56181 or;
b) a wider issue where we collapse coordinating value list longhand
properties to a single value when we shouldn't.
The remaining failing tests in scroll-timeline-shorthand.html are due to
either:
a) incorrect tests, see web-platform-tests/wpt#56181 or;
b) a wider issue where we collapse coordinating value list longhand
properties to a single value when we shouldn't.
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.
We had a partial implementation of transformation function interpolation
that did not support numerical interpolation of simple functions (e.g.
`scale(0)` -> `scale(1)`). This refactors the interpolation to follow
the spec more closely.
Gains us 267 WPT subtest passes in `css/css-transforms`.
Fixes#6774.
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.
Now that we don't remove whitespace when parsing, we don't need to
artificially insert it back in again when serializing. We do now need
to trim leading and trailing whitespace from UnresolvedStyleValues, as
this previously was done as part of the whitespace insertion.
This makes our serialization of UnresolvedStyleValues more correct and
gets us a few WPT passes for each property in the Typed OM tests.
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
Converting to CSSPixels caused us to lose precision and the sign of
signed zeroes.
The values we resolve against in Length::ResolutionContext are still
themselves rounded too early but this is in the right direction.
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.
Passing the `AbstractElement` rather than the
`TreeCountingFunctionResolutionContext` allows us to only compute the
resolution context when necessary (i.e. when we actually need to resolve
a tree counting function)
