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
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)
```
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().
CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed
significantly since we implemented it a couple of years ago. Just about
every parsing algorithm has been rewritten in terms of the new token
stream concept, and to support nested styles. As all of those
algorithms call into each other, this is an unfortunately chonky diff.
As part of this, the transitory types (Declaration, Function, AtRule...)
have been rewritten. That's both because we have new requirements of
what they should be and contain, and also because the spec asks us to
create and then gradually modify them in place, which is easier if they
are plain structs.
Multiple font properties are either the `normal` keyword or some
non-keyword value, so this lets us avoid some boilerplate for those, at
the cost of the existing `none` users having marginally more verbose
code.
This is a special form of `<string>` so doesn't need its own style value
type. It's used in a couple of font-related properties. For completeness
it's included in ValueType.
The following spec algorithms had changed since we implemented them:
- "parse a sizes attribute"
- "update the source set"
- "create a source set"
This commit brings them up to date, as well as adding some additional
logging when parsing the sizes attribute fails in some way.
According to https://www.w3.org/TR/css-grid-2/#placement-shorthands
when setting the 'grid-row' and 'grid-column' shorthand property to a
single <custom-ident> value, both 'grid-row-start'/'grid-column-start'
and 'grid-row-end'/'grid-column-end' should be set to that
<custom_ident>.
Instead of CSSColorValue holding a Gfx::Color, make it an abstract class
with subclasses for each different color function, to match the Typed-OM
spec. This means moving the color calculations from the parsing code to
the `to_color()` method on the style value.
This lets us have calc() inside a color function, instead of having to
fully resolve the color at parse time. The canvas fillStyle tests have
been updated to reflect this.
The other test change is Screenshot/css-color-functions.html: previously
we produced slightly different colors for an alpha of 0.5 and one of
50%, and this incorrect behavior was baked into the test. So now it's
more correct. :^)
"Parse a style value for <foo>", where we don't care if it's a literal
<foo> or a calculated one, is a really common thing that we previously
didn't have methods for.
A couple of methods we had have been extended to parse calc(), and the
others have been filled in.
The method for parsing the `flex` property's value is renamed
`parse_flex_shorthand_value()` as it conflicted.
The values of attribute selectors are now compared case insensitively
by default if the attribute's document is not a HTML document, or the
element is not in the HTML namespace.
For a long time, we've used two terms, inconsistently:
- "Identifier" is a spec term, but refers to a sequence of alphanumeric
characters, which may or may not be a keyword. (Keywords are a
subset of all identifiers.)
- "ValueID" is entirely non-spec, and is directly called a "keyword" in
the CSS specs.
So to avoid confusion as much as possible, let's align with the spec
terminology. I've attempted to change variable names as well, but
obviously we use Keywords in a lot of places in LibWeb and so I may
have missed some.
One exception is that I've not renamed "valid-identifiers" in
Properties.json... I'd like to combine that and the "valid-types" array
together eventually, so there's no benefit to doing an extra rename
now.
As noted, this is hacky because the parser wasn't written to allow
parsing an individual component of a selector. (Fox example, the
convenient-sounding `parse_pseudo_simple_selector()` assumes the first
colon has already been consumed...) So until that changes, this parses
the input as an entire selector-list, and then throws it away if it's
not a single pseudo-element selector.
It's only temporary though, I promise. 😅
These have a few rules that we didn't follow in most cases:
- CSS-wide keywords are not allowed. (inherit, initial, etc)
- `default` is not allowed.
- The above and any other disallowed identifiers must be tested
case-insensitively.
This introduces a `parse_custom_ident_value()` method, which takes a
list of disallowed identifier names, and handles the above rules.
This is `counter(name, style?)` or `counters(name, link, style?)`. The
difference being, `counter()` matches only the nearest level (eg, "1"),
and `counters()` combines all the levels in the tree (eg, "3.4.1").
These control the state of CSS counters.
Parsing code for `reversed(counter-name)` is implemented, but disabled
for now until we are able to resolve values for those.
The new method is Parser::parse_all_as_single_none_value(), which has a
few advantages:
1. There's no need for user code to manually create a StyleValue.
2. It consumes tokens so that doesn't have to be done manually.
3. Whitespace before or after the `none` is consumed correctly.
It does mean we create and then discard a `none` StyleValue in a couple
of places, namely parsing for `grid-*` properties. We may or may not
want to migrate those to returning the IdentifierStyleValue instead.
