Serialization of color names #26
Comments
|
Do we not have enough space available to just store which named colour it was inline? From a quick check, we seem to have 16 bits of padding in |
I may be mistaken, but I think that is the approach the spec takes. The spec says colors generated from the values specified in § 15.2 should be serialized to Other colors are serialized to In other words, I believe the spec says That does mean |
A rough implementation of the ideas in linebender#26 (comment). The ergonomics require some tweaking, and perhaps the performance too, though it should be easy to write this in a form where the compiler can easily optimize the bitwise operations. I haven't verified what the compiler does with the current form. An alternative is to keep `Missing` unchanged, and add something similar to `Flags` as a new field on `DynamicColor`. But adding a new field makes constructing `DynamicColor` a bit less ergonomic.
|
Opened draft #39 for consideration. |
A rough implementation of the ideas in linebender#26 (comment). The ergonomics require some tweaking, and perhaps the performance too, though it should be easy to write this in a form where the compiler can easily optimize the bitwise operations. I haven't verified what the compiler does with the current form. An alternative is to keep `Missing` unchanged, and add something similar to `Flags` as a new field on `DynamicColor`. But adding a new field makes constructing `DynamicColor` a bit less ergonomic.
A rough implementation of the ideas in linebender#26 (comment). The ergonomics require some tweaking, and perhaps the performance too, though it should be easy to write this in a form where the compiler can easily optimize the bitwise operations. I haven't verified what the compiler does with the current form. An alternative is to keep `Missing` unchanged, and add something similar to `Flags` as a new field on `DynamicColor`. But adding a new field makes constructing `DynamicColor` a bit less ergonomic.
A rough implementation of the ideas in linebender#26 (comment). The ergonomics require some tweaking, and perhaps the performance too, though it should be easy to write this in a form where the compiler can easily optimize the bitwise operations. I haven't verified what the compiler does with the current form. An alternative is to keep `Missing` unchanged, and add something similar to `Flags` as a new field on `DynamicColor`. But adding a new field makes constructing `DynamicColor` a bit less ergonomic.
|
The css-color-4 editor’s draft contains some updated language for serializing CSS colors. The spec makes a distinction between serialized declared value and serialized computed value, and neither of them are what we would expect from a “toString()” method in a library.
Two places where these serialized values appear on the web platform:
The distinction between the serialization of declared and computed values is clearer in css-color-5, which introduces relative colors. The serialized declared value keeps the color relative, while the computed value resolves it to an absolute color (in most cases). So to match the CSS spec on the serialization of declared and/or computed values, it does seem the color object needs to store some info on how it was declared. But the library will probably benefit from a CSS-compatible serialization uncoupled from these rules, so that The css-color-5 also offers a mechanism to serialize custom color spaces. Albeit this currently refers to ICC-profiled color spaces, it’s an accepted convention to serialize non-CSS color spaces with an |
A rough implementation of the ideas in linebender#26 (comment). The ergonomics require some tweaking, and perhaps the performance too, though it should be easy to write this in a form where the compiler can easily optimize the bitwise operations. I haven't verified what the compiler does with the current form. An alternative is to keep `Missing` unchanged, and add something similar to `Flags` as a new field on `DynamicColor`. But adding a new field makes constructing `DynamicColor` a bit less ergonomic. --------- Co-authored-by: Daniel McNab <[email protected]>
|
Thank you for the helpful summary! It's interesting the language is updated from "specified" to "declared". For level 4, aside from the language change, I believe the current editor's draft agrees with the current candidate recommendation draft about serializing. In level 5, relative color makes things a bit more complicated, but the section on serializing custom color spaces is a potential answer to a question we were having.
Indeed, that appears to be necessary. |
A rough implementation of the ideas in linebender#26 (comment). The ergonomics require some tweaking, and perhaps the performance too, though it should be easy to write this in a form where the compiler can easily optimize the bitwise operations. I haven't verified what the compiler does with the current form. An alternative is to keep `Missing` unchanged, and add something similar to `Flags` as a new field on `DynamicColor`. But adding a new field makes constructing `DynamicColor` a bit less ergonomic. Squashed: hsl() and hwb() serialize to rgb() Naming consistency Check size only during test Test all named colors Mixed case test Separate into two `u8`s consistency Debug impl Clean up Clippy Use Missing directly Reduce api surface Module name Simplify Debug Module header Inline more Docs --------- Co-authored-by: Daniel McNab <[email protected]>
To perform correct CSS Color 4 serialization of colors, some details of how a color was declared have to be preserved. Specifically, [CSS Color Module Level 4 § 15.2](https://www.w3.org/TR/css-color-4/#serializing-sRGB-values) and the two sections on Lab and Oklab following it specify that - a color declared as a named CSS/X11 color, should serialize to that (normalized) color name; and - a color declared as one of the named color space functions – i.e., _not_ the `color()` function – should serialize to that function. (Exceptions being `hsl()` and `hwb()`, those serialize to `rgb()`.) This implementation uses the padding currently available on `DynamicColor` to pack in the color name the `DynamicColor` was created from, or whether a named color space function was used; an implementation of the ideas in #26 (comment). `DynamicColor` now contains `Flags`, and the existing `Missing` color components are moved into `Flags`. In this implementation, only `parse_color` sets the color name or color space function name. --------- Co-authored-by: Daniel McNab <[email protected]>
There's a basic question that needs a decision (though it doesn't have to happen right now), and some more subtle considerations.
The serialization section of the CSS Color 4 spec requires that a parse of
"red"serializes as"red", not"rgb(255, 0, 0)"or"#ff0000". I can see this as potentially useful in applications that process CSS for output to the web, improving human readability. We could do it, but it has some cost and complexity.The outline of how I'd do it is reserve another bit in
Missing(which I'd probably rename "Flags" or somesuch) indicating that it's a named color. Then, when serializing, if the bit is set, the color would be rounded to rgba8, the named color table would be searched, and, if there's a match, the name output. If there's not a match, then it would be serialized as if the bit were not set. The search could be implemented at least 3 ways: linear scan (slow-ish but simple and with no additional data burden), phf (tricky, estimated 284 bytes), or binary search using an additional 142 byte permutation table representing the sort by u32.But this touches a deeper problem. There is some potentially some divergence between what we want for string output, and strict CSS serialization. Aside from the named colors, we need to serialize out-of-gamut srgb using the
colorfunction andsrgbcolorspace, rather than thergbfunction, as the latter clips. Also, if we have color spaces not covered by CSS (#14, #15, possibly others), then those won't serialize to a valid CSS string.One solution is that we do our own thing for
Displayon our color types that is not necessarily CSS compatible, and have another way to do strictly CSS compatible serialization. I'd lean toward doing that asDisplayimpl on aCssFormatwrapper type, and also have that feature gated, but am open to other ideas.The text was updated successfully, but these errors were encountered: