Corresponds to part of:
e9ccb97eb1
The majority of that spec change is in algorithms that we don't yet
implement. So this is just a small text change and an update to use
as_if() instead of static_cast().
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
Previously we would either parse these as `StyleValueList<T>` or `T`
depending on whether or not there was more than one value, this meant we
always had to handle both cases anywhere we used these values.
Previously we were doing a couple things wrong:
- Using the cascaded rather than computed value (so we didn't support
CSS-wide keywords)
- Only supporting the case where we had one animation-play-state
The recent commits 28ba610f32 and
70c4ed261f adjusted some include
directives to avoid excessive recompilation when changing some header
files. This has broken compilation with clang-cl on Windows without
getting noticed before the PRs were merged.
Some of this is rearranged for clarity, but it's mostly the exact same
code. Steps 3, 10, 11, and 15 are new, but don't have any effect until
we implement downward-growing cells.
Corresponds to:
93634aed57
The current live spec has been rearranged since this went in, so that
these steps are no longer located here. But that's a much larger change
that I don't want to implement right now. See here:
e09d10202d
While I was at it, I also made use of extract_error_information() to
populate the ErrorEvent.
I missed where this change happened in the spec. The second half of
abort_the_ongoing_navigation() becomes a separate method, which is
slightly rearranged. I've placed this in Navigation instead of
NavigateEvent because of how many steps poke at the Navigation's
internals.
The text here includes the amendments I made in
https://github.com/whatwg/html/pull/11967 to correct a variable name.
A bonus is that we now actually populate the ErrorEvent instead of
leaving it blank.
There are a couple of remaining RFC 9111 methods in LibWeb's Fetch, but
these are currently directly tied to the way we store GC-allocated HTTP
response objects. So de-coupling that is left as a future exercise.
This factors the conversion logic to be independent from WebGL code,
allowing us to write unit tests for it that can run in CI (since WebGL
can't run in CI).
The `Bitmap` type was referring to to its internal pixel format by a
name that represents the order of the color components as they are layed
out in memory. Contrary, the `Color` type was using a naming that where
the name represents the order of the components from most to least
significant byte when viewed as a unsigned 32bit integer. This is
confusing as you have to keep remembering which mental model to use
depending on which code you work with.
To unify the two, the naming of RGBA-like colors in the `Color` type has
been adjusted to match the one from the Bitmap type. This seems to be
generally in line with how web APIs think about these types:
* `ImageData.pixelFormat` can be `rgba-8unorm` backed by a
`Uint8ClamedArray`, but there is no pixel format backed by a 32bit
unsigned type.
* WebGL can use format `RGBA` with type `UNSIGNED_BYTE`, but there is no
such format with type `UNSIGNED_INT`.
Additionally, it appears that other browsers and browser-adjacent
libraries also think similarly about these types:
* Firefox:
https://github.com/mozilla-firefox/firefox/blob/main/gfx/2d/Types.h
* WebKit:
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/graphics/PixelFormat.h
* Skia:
https://chromium.googlesource.com/skia/+/refs/heads/main/include/core/SkColorType.h
This has the not so nice side effect that APIs that interact with these
types through 32bit unsigned integers now have the component order
inverted due to little-endian byte order. E.g. specifying a color as hex
constant needs to be done as `0xAABBGGRR` if it is to be treated as
RGBA8888.
We could alleviate this by providing endian-independent APIs to callers.
But I suspect long-term we might want to think differently about bitmap
data anyway, e.g. to better support HDR in the future. However, such
changes would be more involved than just unifying the naming as done
here. So I considered that out of scope for now.
