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.
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