This is really bare bone as we only support the `xyz-d50` color space
for the moment.
It makes us pass the following WPT tests:
- css/css-color/predefined-016.html
- css/css-color/xyz-d50-001.html
- css/css-color/xyz-d50-002.html
All its overrides return constants, and without virtual dispatch the
`qualified_layer_name` and `absolutized_selectors` functions can benefit
from slightly better optimizations.
`CSSRule`s aren't allocated that often, so the memory impact is minimal.
The traversal for these was incorrect and awkward. Now it's less
incorrect but still very awkward. We should find better ways to
implement this, but for now this at least passes many more WPT tests.
The support in LibWeb is quite easy as the previous commits introduced
helpers to support lab-like colors.
Now for the methods in Color:
- The formulas in `from_lab()` are derived from the CIEXYZ to CIELAB
formulas the "Colorimetry" paper published by the CIE.
- The conversion in `from_xyz50()` can be decomposed in multiple steps
XYZ D50 -> XYZ D65 -> Linear sRGB -> sRGB. The two first conversion
are done with a singular matrix operation. This matrix was generated
with a Python script [1].
This commit makes us pass all the `css/css-color/lab-00*.html` WPT
tests (0 to 7 at the time of writing).
[1] Python script used to generate the XYZ D50 -> Linear sRGB
conversion:
```python
import numpy as np
# http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html
# First let's convert from D50 to D65 using the Bradford method.
m_a = np.array([
[0.8951000, 0.2664000, -0.1614000],
[-0.7502000, 1.7135000, 0.0367000],
[0.0389000, -0.0685000, 1.0296000]
])
# D50
chromaticities_source = np.array([0.96422, 1, 0.82521])
# D65
chromaticities_destination = np.array([0.9505, 1, 1.0890])
cone_response_source = m_a @ chromaticities_source
cone_response_destination = m_a @ chromaticities_destination
cone_response_ratio = cone_response_destination / cone_response_source
m = np.linalg.inv(m_a) @ np.diagflat(cone_response_ratio) @ m_a
D50_to_D65 = m
# https://en.wikipedia.org/wiki/SRGB#From_CIE_XYZ_to_sRGB
# Then, the matrix to convert to linear sRGB.
xyz_65_to_srgb = np.array([
[3.2406, - 1.5372, - 0.4986],
[-0.9689, + 1.8758, 0.0415],
[0.0557, - 0.2040, 1.0570]
])
# Finally, let's retrieve the final transformation.
xyz_50_to_srgb = xyz_65_to_srgb @ D50_to_D65
print(xyz_50_to_srgb)
```
This change also removes as much direct use of JS::Promise in LibWeb
as possible. When specs refer to `Promise<T>` they should be assumed
to be referring to the WebIDL Promise type, not the JS::Promise type.
The one exception is the HostPromiseRejectionTracker hook on the JS
VM. This facility and its associated sets and events are intended to
expose the exact opaque object handles that were rejected to author
code. This is not possible with the WebIDL Promise type, so we have
to use JS::Promise or JS::Object to hold onto the promises.
It also exposes which specs need some updates in the area of
promises. WebDriver stands out in this regard. WebAudio could use
some more cross-references to WebIDL as well to clarify things.
This implementation is incomplete in that we do not fully implement the
steps to match the given font against the fonts in the set.
This is used by fonts.google.com to load the fonts used for sample text.
This is strictly nicer than passing them around as i32 everywhere,
and by switching to i64 as the underlying type, ID allocation becomes as
simple as incrementing an integer.
For pseudo elements that represent a browser-generated shadow tree
element, such as ::placeholder, we were reparsing their style attribute
in StyleComputer for some reason.
Instead of doing this, just access the already-parsed version via
Element::inline_style().
These are created when a style rule has properties listed after another
rule. For example:
```css
.test {
--a: 1;
--b: 1;
--c: 1;
.thing {
/* ... */
}
/* These are after a rule (.thing) so they're wrapped in a
CSSNestedDeclarations: */
--d: 1;
--e: 1;
--f: 1;
}
```
They're treated like a nested style rule with the exact same selectors
as their containing style rule.
For example, this:
```css
.foo {
color: red;
&:hover {
color: green;
}
}
```
now has the same effect as this:
```css
.foo {
color: red;
}
.foo:hover {
color: green;
}
```
CSSStyleRule now has "absolutized selectors", which are its selectors
with any `&`s resolved. We use these instead of the "real" selectors
when matching them, meaning the style computer doesn't have to know or
care about where the selector appears in the CSS document.
Through the CSSOM, rules can be moved around, and so anything cached
(for now just the qualified layer name) needs to be recalculated when
that happens. This method is virtual so that other rules will be able
to clear their cached data too.
A couple of parts of this:
- Store the source text for Declarations of custom properties.
- Then save that in the UnresolvedStyleValue.
- Serialize UnresolvedStyleValue using the saved source when available -
that is, for custom properties but not for regular properties that
include var() or attr().
This is in a weird position where the spec tells us to discard the
comments, but then we have to preserve the original source text which
may include comments. As a compromise, I'm treating each comment as a
whitespace token - comments are functionally equivalent to whitespace
so this should not have any behaviour changes beyond preserving the
original text.
Previously we would serialize these as the empty string. eg, this:
```
<div style="grid-auto-columns: auto"></div>
```
would have a computed `grid-auto-columns` value of ``.
In order to know whether `calc(2.5)` is a number or an integer, we have
to see what the property will accept. So, add that knowledge to
`Parser::expand_unresolved_values()`.
This makes `counter-increment: foo calc(2 * var(--n));` work correctly,
in a test I'm working on.
This will be the first step is making better use of system libraries
like fontconfig and CoreText to load system fonts for use by the UI
process and the CSS style computer.
