Support color spaces by mirisuzanne · Pull Request #2832 · sass/sass

mirisuzanne · 2020-03-09T17:59:15Z

proposal/color-4-new-formats.md

mirisuzanne · 2022-08-26T23:29:00Z

The summary section still needs fleshing out, and I'm sure I have some typos and broken links in there - but I think the overall proposal is ready for a round of review. It's a big one! 😅

stof · 2022-08-27T11:01:00Z

The commit history is totally broken. I suspect that at some point, master was rebased on top of the branch instead of the opposite

mirisuzanne · 2022-08-29T15:26:08Z

I can close and reopen without all the history, if that's helpful.

nex3 · 2022-08-30T22:37:09Z

proposal/color-4-new-spaces.md

+$brighter-green: color(display-p3 0 1 0);
+```
+
+<!-- flesh this out more -->


I think it's particularly worth giving an overview here of the "rules of thumb" for how colors will now work in Sass. IIRC:

Colors defined in one space stay in that space (and are emitted in that space) unless explicitly changed.

You can always convert a color to widely-compatible sRGB format using ....

Functions that work different ways in different spaces use the color's space by default but also have an explicit $space parameter.

"Legacy colors" come from ... and are always emitted in a compatible format.

Also, list the new functions with brief documentation for each of them, list the functions that are being deprecated, and other such changes to the core modules.

nex3 · 2022-08-30T22:38:17Z

proposal/color-4-new-spaces.md

+   or allow out-of-gamut colors in output. Browsers will also provide improved
+   gamut mapping, based on the user device capabilities.


I would emphasize here that we don't clamp colors because browsers do better gamut-mapping than we possibly can.

nex3 · 2022-08-30T22:39:09Z

proposal/color-4-new-spaces.md

+
+1. Channel values are no longer clamped to the gamut of a given color space.
+   Authors can use the provided `to-gamut()` function to map colors into gamut,
+   or allow out-of-gamut colors in output. Browsers will also provide improved


I think "or allow" is a little confusing here, because it sounds like it's an explicit choice the author is making when (I believe) it's just the default. Maybe instead: "but by default Sass will emit out-of-gamut colors".

nex3 · 2022-08-30T22:39:56Z

proposal/color-4-new-spaces.md

+   Authors can use the provided `to-gamut()` function to map colors into gamut,
+   or allow out-of-gamut colors in output. Browsers will also provide improved
+   gamut mapping, based on the user device capabilities.
+2. Channel values are no longer rounded to the nearest integer, since the spec


I'd explicitly say "RGB channel values", since we never rounded HSL channel values.

nex3 · 2022-08-30T22:40:25Z

proposal/color-4-new-spaces.md

+While we are not attempting to support all of [CSS Color Level 5][color-5] at
+this point, we have used it as a reference while updating color manipulation


Probably worth mentioning that we aren't support Color 5 because it's not in browsers yet.

nex3 · 2022-08-31T01:52:12Z

proposal/color-4-new-spaces.md

+* Return the result of calling `color.adjust()` with `$color`, a $hue of
+  `180deg`, and a $space of `space`.


Suggested change

* Return the result of calling `color.adjust()` with `$color`, a $hue of

`180deg`, and a $space of `space`.

* Return the result of calling `color.adjust($color, $hue: 180deg, $space: space)`.

You don't have to use prose when it gets in the way :-). Similarly elswhere.

nex3 · 2022-08-31T01:54:13Z

proposal/color-4-new-spaces.md

+    > This currently allows `hsl`, `hwb`, `lch`, and `oklch`. We could also
+    > map some cubic spaces with matching gamuts e.g. (`oklab` -> `oklch`),
+    > but that adds implicit complexity, while still excluding color spaces.


It looks like we do do this mapping for color.invert()—either way we should be consistent.

nex3 · 2022-08-31T01:57:23Z

proposal/color-4-new-spaces.md

+### `color.invert()`
+
+```
+invert($color, $space)


The existing color.invert() function also supports a $weight parameter (which it just tosses into $mix at the end).

nex3 · 2022-08-31T01:59:04Z

proposal/color-4-new-spaces.md

+
+* If `$space` is undefined:
+
+  * If `$color` is a legacy color, let `space` be `hsl`.


Shouldn't this be rgb to match the current behavior?

proposal/color-4-new-spaces.md

stof · 2022-09-01T09:28:31Z

proposal/color-4-new-spaces.md

+
+  * If `$space` is not a [color space][], throw an error.
+
+  * Return the result of [converting][] the `origin-color`


I think this misses an error for the case where $space or origin-space are unknown spaces, because the current conversion algorithm only supports known spaces.

stof · 2022-09-01T09:29:18Z

proposal/color-4-new-spaces.md

+  * If `$space` is null:
+
+    * Let `color` be the value of `color`, and let `space` be the result of
+      calling `space($color)`.


Suggested change

calling `space($color)`.

calling `color.space($color)`.

proposal/color-4-new-spaces.md

stof · 2022-09-01T09:31:46Z

proposal/color-4-new-spaces.md

+  * Let `target-space` be the value of `$space` if specified, or the value of
+    `origin-space` otherwise.
+
+  * If `target-space` is not a valid [color space][], throw an error.


is valid color space here meant to mean known color space ?

stof · 2022-09-01T09:35:43Z

proposal/color-4-new-spaces.md

+  ```
+
+  > This overload exists to support Microsoft's proprietary [`alpha()`
+  > function][].


shouldn't we deprecate that overload in the namespaced function ?

For now, I've removed this entire alpha() section based on Natalie's comments above, since it doesn't make any changes. Not sure if we want to add a special mention of this overload in the deprecations section?

stof · 2022-09-01T09:40:36Z

proposal/color-4-new-spaces.md

+
+  * If `$space` is 'lab', let `space` be `lch`.
+
+  * Otherwise, if `$space` is 'oklab', let `space` be `oklch`.


there is a mix between quotes and backticks around color space names here.

stof · 2022-09-01T09:49:30Z

proposal/color-4-new-spaces.md

+
+    * Otherwise, append the last element of `input` to `components`
+
+  * If `components` is undefined or an empty list, throw an error.


it indeed seems always assigned

dvdherron · 2022-09-05T11:39:47Z

proposal/color-4-new-spaces.md

+[CSS Color Level 4][color-4]. Since the CIE color space defines the entire
+gamut of visible color, much larger than the target sRGB gamut, out-of-range
+color definitions will be clipped using a *relative-colorimetric* approach that
+leaves in-gamut colors un-affected.


Suggested change

leaves in-gamut colors un-affected.

leaves in-gamut colors unaffected.

dvdherron · 2022-09-05T12:01:20Z

proposal/color-4-new-spaces.md

+        element of `split-last` to `components`.
+
+      > This solves for a legacy handling of `/` in Sass that would produce an
+      > unquoted string when the alpha value is a css function such as `var()`


Suggested change

> unquoted string when the alpha value is a css function such as `var()`

> unquoted string when the alpha value is a CSS function such as `var()`

dvdherron · 2022-09-05T12:02:31Z

proposal/color-4-new-spaces.md

+      * Let `alpha` be the number after the slash, and append the number before
+        the slash to `components`.
+
+    * Otherwise, append the last element of `input` to `components`


Suggested change

* Otherwise, append the last element of `input` to `components`

* Otherwise, append the last element of `input` to `components`.

dvdherron · 2022-09-05T12:23:00Z

proposal/color-4-new-spaces.md

+  $method: null)
+```
+
+* If `$method` undefined:


Suggested change

* If `$method` undefined:

* If `$method` is undefined:

dvdherron · 2022-09-05T12:28:57Z

proposal/color-4-new-spaces.md

+
+* If either `color1` or `color2` is not a color, throw an error.
+
+* If `weight` is undefined, set `weight` to `50%`.


Suggested change

* If `weight` is undefined, set `weight` to `50%`.

* If `weight` is null, set `weight` to `50%`.

dvdherron · 2022-09-05T12:29:44Z

proposal/color-4-new-spaces.md

+
+* If `$color` is not a color, throw an error.
+
+* If `$space` is undefined:


Suggested change

* If `$space` is undefined:

* If `$space` is null:

dvdherron · 2022-09-05T12:30:32Z

proposal/color-4-new-spaces.md

+
+  * If `input` is a [special variable string][], return `null`.
+
+  * Let `include-space` be true if `space` is undefined, and false otherwise.


Suggested change

* Let `include-space` be true if `space` is undefined, and false otherwise.

* Let `include-space` be true if `space` is null, and false otherwise.

dvdherron · 2022-09-05T12:33:48Z

proposal/color-4-new-spaces.md

+  * Let `gray` be the result of `whiteness + blackness`.
+
+  * Return the result of calling `color.change()` with `color`, a $hue of `hue`,
+    $whiteness of `gray - whiteness`, and $blackness of `gray - blackness`.


Suggested change

$whiteness of `gray - whiteness`, and $blackness of `gray - blackness`.

$whiteness of `gray - whiteness`, and `$blackness` of `gray - blackness`.

dvdherron · 2022-09-05T12:42:05Z

proposal/color-4-new-spaces.md

+
+    * If `components` is not an unbracketed space-separated list, throw an error.
+
+    * If `space` is undefined, let `space` be the first element in `components`,


Suggested change

* If `space` is undefined, let `space` be the first element in `components`,

* If `space` is null, let `space` be the first element in `components`,

mirisuzanne · 2022-09-05T22:42:57Z

Thank you for the very helpful comments @nex3, @stof, and @dvdherron - it's a big proposal, so easy to get lost & miss things. :) I think I've addressed most of the comments, and would be happy for another look when you're able.

I added a number of additional global color functions for deprecation, but haven't yet removed/changed any notes referencing them (e.g. notes like This function is also available as a global function named grayscale()). I wasn't sure 1) if we want all those functions deprecated, or 2) how to handle those notes if they are deprecated - but I assume we may still need some changes there.

stof · 2022-09-05T23:29:22Z

proposal/color-4-new-spaces.md

+  shown significant benefits by providing a more *perceptually uniform*
+  distribution of colors, so that similar mathematical adjustments achieve
+  visually similar results.
+- A *color space* is the result of projecting a color model into a coordinate


Those definitions look weird to me. What you call a "color model" here is exactly what the CSS spec calls a "color space". Color spaces are sRGB, CIE Lab and OKLab, not RGB or HSL. What you call a color space here is called a coordinate system of the color space in the CSS spec.
I think we should align the terminology to avoid confusion.

Reading more in details, I think there is a confusion in the CSS spec between the terminology defined at the beginning of the spec and the the <color-space> production in the defined syntax.

Yeah, I can try to make some clarifications here, but I think we're technically aligned with the spec already.

To some extent it's just a problem of confusing and overlapping terms. OKLab & RGB are both color models, and also color spaces (which means they are also coordinate systems). The CSS spec doesn't define color model as a term, they only reference it in the color space term definition. I think the CSS spec is also a bit inconsistent about when they say 'color space' and when they say 'coordinate system'.

Both of us are also blurring 'color space' with 'color function' a bit, since they're mostly one-to-one, and defining them that way is easier to explain to authors. But that gets a bit tangled, since rgb and srgb are technically the same space, just using legacy and non-legacy functions. There's no reason for CSS to provide both as part of a <color-space> production for 'color interpolation method', but it is useful for us to distinguish between them as a way of tracking legacy vs non-legacy colors. By keeping rgb as a distinct space, we no longer need the is-legacy boolean.

The other confusion here is that we used non-overlapping examples for an overlapping concept. In my definition, I used legacy function examples for color spaces (rgb and hsl). In their definition examples, they used only color spaces in the color() function. Both are accurate. Both srgb and hsl are color spaces.

Co-authored-by: Christophe Coevoet <stof@notk.org>

nex3

Some things that aren't covered here yet:

Throwing errors for NaN/infinity.
Serializing non-legacy colors.

I wasn't sure 1) if we want all those functions deprecated, or 2) how to handle those notes if they are deprecated - but I assume we may still need some changes there.

Generally when a proposal makes backwards-incompatible changes to behavior, the main body of the proposal just says what the eventual new behavior will be (in this case, this would mean "these functions always throw errors"). Then in a Deprecation Process section at the bottom of the spec, it describes how existing implementations should deprecate their current behavior in preparation for becoming spec-compliant.

The general idea here is that, if a new implementation were to come along, it should just implement the primary spec—it wouldn't be obligated to match Dart Sass deprecation-for-deprecation.

nex3 · 2022-09-06T22:33:45Z

proposal/color-4-new-spaces.md

+a color function. The 'RGB' color space is identical to the 'sRGB' space, and
+both describe the 'sRGB' gamut. But we have both `rgb()` and `color(srgb)`
+syntax, in order to distinguish legacy from non-legacy variations. Some new


Might also be worth mentioning that RGB and sRGB have different coordinate systems, since RGB goes from 0-255 and sRGB goes from 0-1.

nex3 · 2022-09-06T22:41:27Z

proposal/color-4-new-spaces.md

+
+There are several rules of thumb for working with color spaces in Sass:
+
+- The `rgb`, `hsl`, and `hwb` spaces are considered 'legacy spaces', and will


Nit: this would be more readable in plain-text form with empty lines between the list elements.

nex3 · 2022-09-06T22:41:58Z

proposal/color-4-new-spaces.md

+- The `srgb` color space is equivalent to `rgb`, except that one is a legacy
+  space, and the other is not.


Also the coordinate systems!

nex3 · 2022-09-06T22:44:15Z

proposal/color-4-new-spaces.md

+  provided for manipulation, the resulting color will still be returned in the
+  same space as the origin color. For `color.mix()`, the first color parameter
+  is considered the origin color.
+- All legacy and RGB spaces represent bounded gamuts of color. When converting (


I wonder if we can find a better term than "RGB spaces", since a naive reader will probably assume it means either "the rgb color space" or "the rgb or srgb color spaces". Maybe "RGB-style spaces"?

nex3 · 2022-09-06T22:44:27Z

proposal/color-4-new-spaces.md

+  provided for manipulation, the resulting color will still be returned in the
+  same space as the origin color. For `color.mix()`, the first color parameter
+  is considered the origin color.
+- All legacy and RGB spaces represent bounded gamuts of color. When converting (


Suggested change

- All legacy and RGB spaces represent bounded gamuts of color. When converting (

- All legacy and RGB spaces represent bounded gamuts of color. When converting

nex3 · 2022-09-07T00:40:09Z

proposal/color-4-new-spaces.md

+are considered _out of gamut_ for the given color space. If the channel is
+bounded, or has a percentage mapping with a lower-boundary of zero, then the
+channel is considered _scalable_.


This term "scalable" isn't actually referenced anywhere. Is it supposed to be referenced in color.scale()?

nex3 · 2022-09-07T00:44:15Z

proposal/color-4-new-spaces.md

+
+  * Let `gray` be the result of `whiteness + blackness`.
+
+  * Let `white` be `gray - whiteness`, and let `black` be `gray - blackness`.


This will always just set white to blackness and black to whiteness.

nex3 · 2022-09-07T00:45:25Z

proposal/color-4-new-spaces.md

+
+      * Let `new` be `(channel + 180deg) % 360deg`.
+
+    * Otherwise, if `channel` represents either chroma or saturation:


"represents" is somewhat underspecified here. Maybe just say "if channel's name is either chroma or saturation"

nex3 · 2022-09-07T00:48:35Z

proposal/color-4-new-spaces.md

+
+* Otherwise:
+
+  * Let `origin` be `$color`'s [known color space].


What if its color space isn't known?

nex3 · 2022-09-07T00:49:34Z

proposal/color-4-new-spaces.md

+
+* If `$color` is not a color, throw an error.
+
+* Let `rgb` be the result of [converting] `$color` to `rgb`.


I think this should gamut-map too, since there's no way to represent out-of-gamut colors in the 8-digit hex format.

mirisuzanne · 2022-09-07T20:21:10Z

Still a few ToDo items here:

re-organize deprecated functions
serialization for non-legacy colors
make a small "Look Up a Known Color Space" procedure that maps a SassScript argument to a color space?

proposal/color-4-new-spaces.md

Co-authored-by: david herron <41588129+dvdherron@users.noreply.github.com>

proposal/color-4-new-spaces.md

mirisuzanne · 2022-09-19T19:19:47Z

I think all the outstanding issues here have been addressed. Ready for another round of review.

nex3

One more round of review—we should be good to go after this!

nex3 · 2022-09-20T01:53:32Z

proposal/color-4-new-spaces.md

+* Mapping colors into a gamut is a lossy process. Whenever possible, it should
+  be left to the browser, which can map colors based on a given user's display
+  capabilities. However, authors can perform explicit gamut mapping with the
+  `color.to-gamut()` function.


This seems mostly redundant with the last bullet point, other than mentioning color.to-gamut(). Maybe the two should be merged?

nex3 · 2022-09-20T02:00:30Z

proposal/color-4-new-spaces.md

+
+[known color space]: #known-color-space
+
+#### Serialization of Non-Legacy Colors


This should probably be in a separate "Serialization" section.

nex3 · 2022-09-20T02:01:49Z

proposal/color-4-new-spaces.md

+
+  * Emit "color(", followed by `color-space`, " ", `components`, and then ")".
+
+* Otherwise, emit `color-space` followed by "(", `components`, and then ")".


It looks like this will emit unknown color spaces as their own Sass functions, which I think is incorrect. We should probably explicitly list the color spaces that have their own function names, and emit the color() function as the default.

nex3 · 2022-09-20T02:08:13Z

proposal/color-4-new-spaces.md

+
+To serialize a non-legacy color `color`:
+
+* Let `components` be a space-separated list of `color`'s channel values.


Channel values aren't intrinsically SassScript values, so this should explain how to convert from the one to the other. In particular:

Which units (if any) do which channels have?

What SassScript value should missing channels have?

nex3 · 2022-09-20T02:11:27Z

proposal/color-4-new-spaces.md

+with a matching name. It throws an error if `name` is not a valid color space
+name, and either returns the known color space, or `name` if no color space is
+matched.


It's kind of confusing that this can return either a color space or the name of a color space—it means that any spec invoking this procedure could end up working with two different "types". Maybe it should just return null if the space isn't known?

nex3 · 2022-09-20T03:02:36Z

proposal/color-4-new-spaces.md

+
+* For each keyword `key` and value `new` in `channel-args`:
+
+  * If `new` is not a number or the special value `none`, throw an error.


Same comment as above: we need to be explicit about how to recognize a SassScript value that indicates none.

nex3 · 2022-09-20T03:05:20Z

proposal/color-4-new-spaces.md

+
+* If the keyword argument `$alpha` is specified in `$args`:
+
+    * If `alpha == none`, throw an error.


Why not treat it as zero? Or potentially just keep it as none?

I don't think CSS Colors 4 defines a valid usage of none for the alpha value. IIRC, it only has none for color space channels, not for the alpha.

The current spec does allow alpha components to be set to none - see eg https://drafts.csswg.org/css-color-4/#missing:

All color functions allow any of their components to be specified as none.

and https://drafts.csswg.org/css-color-4/#funcdef-rgb for explicit mention in a color function.

But yes, I think we can treat none as 0 in this case. Making that change.

nex3 · 2022-09-20T03:06:52Z

proposal/color-4-new-spaces.md

+  * Set the `channel` with name or index of `key` in `channels` to
+    `channel + adjust`, treating values of `none` as `0`.


Since none indicates that the channel value is irrelevant, should we just preserve it as-is even if an adjustment is made to it?

I would expect adjust() and scale() to have the same behavior here. Likely choosing between:

Maintain none as an irrelevant channel. This strikes me as potentially confusing for authors, since it results in no change and no notification?

Adjust/scale from 0.

Throw an error.

CSS color 5 has a similar situation, where color channels can be adjusted in a relative color syntax. I don't see it clearly defined in that spec what should happen when missing channels are adjusted. I think it would be great to follow their lead if we're able? I've reached out to Chris, and can also open an issue in CSS. My expectation would be either adjusting-from-0, or considering it an invalid operation.

nex3 · 2022-09-20T03:09:46Z

proposal/color-4-new-spaces.md

+
+  * Let `max` be the upper boundary of `channel` in `space`.
+
+  * If `channel > max` or `channel < 0`, throw an error.


I'd like to avoid throwing errors in these functions as much as possible unless the user is doing something clearly incoherent. We can reasonable scale sub-0 channels up and supramaximum channels down; if the user tries to scale them in the opposite direction, I think we should just keep them as-is, since that's the asymptotic behavior approaching min/max.

nex3 · 2022-09-20T03:13:34Z

proposal/color-4-new-spaces.md

+* Let `color` be the result of [converting] and [gamut mapping] `$color`
+  into the color space `space`.


Do we need to gamut-map here? We can theoretically meaningfully invert color(srgb 2 -0.5 0.3) into color(srgb -1 1.5 0.7), right?

nex3

Thanks for all your work on this proposal, Miriam!

vpetreski approved these changes Mar 10, 2020

View reviewed changes

stof reviewed Sep 28, 2021

View reviewed changes

proposal/color-4-new-formats.md Outdated Show resolved Hide resolved

proposal/color-4-new-formats.md Outdated Show resolved Hide resolved

proposal/color-4-new-formats.md Outdated Show resolved Hide resolved

mirisuzanne marked this pull request as ready for review August 26, 2022 23:27

nex3 requested changes Aug 31, 2022

View reviewed changes

stof reviewed Sep 1, 2022

View reviewed changes

dvdherron reviewed Sep 5, 2022

View reviewed changes

stof reviewed Sep 5, 2022

View reviewed changes

mirisuzanne and others added 9 commits September 6, 2022 15:28

Background and summary

794658b

Fix typos

3dda994

Co-authored-by: Christophe Coevoet <stof@notk.org>

Proposed support for color spaces

ec109f1

Update table of contents

615db6c

Address review, and specify interpolation of missing channels

c67d727

Unquote none

cd42364

Expand on summary and design decisions

684947e

More detailed overview of terms

6dd688b

Remove deprecations for alias functions

909a1f2

nex3 force-pushed the color-4-formats branch from 306e804 to 909a1f2 Compare September 6, 2022 22:29

nex3 requested changes Sep 7, 2022

View reviewed changes

Update ToC

f71df18

nex3 force-pushed the color-4-formats branch from a14e3a1 to f71df18 Compare September 7, 2022 01:38

Address review comments, and handle NaN/infinity

beed1a6

mirisuzanne added 2 commits September 7, 2022 14:24

Update toc

89a58f1

Define color equality and the color.same() function

efa2fc6

dvdherron reviewed Sep 8, 2022

View reviewed changes

typo fix

f027c02

Co-authored-by: david herron <41588129+dvdherron@users.noreply.github.com>

Link to published color-4 rather than editor's draft

e147534

Co-authored-by: david herron <41588129+dvdherron@users.noreply.github.com>

mirisuzanne commented Sep 9, 2022

View reviewed changes

proposal/color-4-new-spaces.md Outdated Show resolved Hide resolved

mirisuzanne added 5 commits September 9, 2022 15:51

Update proposal/color-4-new-spaces.md

24e48e8

Define color-space lookup, and legacy interpolation procedures

5e33341

Improvements to color.channel() with alpha special-case

1061176

Draft serialition of non-legacy colors

c696db9

Split function deprecation from deprecation process

7c61475

nex3 self-requested a review September 20, 2022 01:48

nex3 requested changes Sep 20, 2022

View reviewed changes

Address review comments

b7727e8

nex3 approved these changes Sep 21, 2022

View reviewed changes

nex3 changed the title ~~Provide Sass functions for new color formats: hwb, lab, and lch~~ Support color spaces Sep 21, 2022

nex3 merged commit 5f70018 into main Sep 21, 2022

nex3 deleted the color-4-formats branch September 21, 2022 01:06

		or allow out-of-gamut colors in output. Browsers will also provide improved
		gamut mapping, based on the user device capabilities.

		While we are not attempting to support all of [CSS Color Level 5][color-5] at
		this point, we have used it as a reference while updating color manipulation

		* Return the result of calling `color.adjust()` with `$color`, a $hue of
		`180deg`, and a $space of `space`.


		* If `$space` is undefined:

		* If `$color` is a legacy color, let `space` be `hsl`.


		* If `$space` is not a [color space][], throw an error.

		* Return the result of [converting][] the `origin-color`


		* If `$space` is 'lab', let `space` be `lch`.

		* Otherwise, if `$space` is 'oklab', let `space` be `oklch`.


		* Otherwise, append the last element of `input` to `components`

		* If `components` is undefined or an empty list, throw an error.

	leaves in-gamut colors un-affected.
	leaves in-gamut colors unaffected.

	> unquoted string when the alpha value is a css function such as `var()`
	> unquoted string when the alpha value is a CSS function such as `var()`


		* If either `color1` or `color2` is not a color, throw an error.

		* If `weight` is undefined, set `weight` to `50%`.

	* If `weight` is undefined, set `weight` to `50%`.
	* If `weight` is null, set `weight` to `50%`.


		* If `$color` is not a color, throw an error.

		* If `$space` is undefined:


		* If `input` is a [special variable string][], return `null`.

		* Let `include-space` be true if `space` is undefined, and false otherwise.

	$whiteness of `gray - whiteness`, and $blackness of `gray - blackness`.
	$whiteness of `gray - whiteness`, and `$blackness` of `gray - blackness`.


		* If `components` is not an unbracketed space-separated list, throw an error.

		* If `space` is undefined, let `space` be the first element in `components`,

	* If `space` is undefined, let `space` be the first element in `components`,
	* If `space` is null, let `space` be the first element in `components`,


		There are several rules of thumb for working with color spaces in Sass:

		- The `rgb`, `hsl`, and `hwb` spaces are considered 'legacy spaces', and will

		- The `srgb` color space is equivalent to `rgb`, except that one is a legacy
		space, and the other is not.

	- All legacy and RGB spaces represent bounded gamuts of color. When converting (
	- All legacy and RGB spaces represent bounded gamuts of color. When converting


		* Let `gray` be the result of `whiteness + blackness`.

		* Let `white` be `gray - whiteness`, and let `black` be `gray - blackness`.

Conversation

mirisuzanne commented Mar 9, 2020

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mirisuzanne commented Aug 26, 2022

Uh oh!

stof commented Aug 27, 2022

Uh oh!

mirisuzanne commented Aug 29, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mirisuzanne commented Sep 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nex3 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mirisuzanne commented Sep 5, 2022 •

edited

Loading

mirisuzanne commented Sep 7, 2022 •

edited

Loading


		* Let `new` be `(channel + 180deg) % 360deg`.

		* Otherwise, if `channel` represents either chroma or saturation:


		* Otherwise:

		* Let `origin` be `$color`'s [known color space].


		* If `$color` is not a color, throw an error.

		* Let `rgb` be the result of [converting] `$color` to `rgb`.


		[known color space]: #known-color-space

		#### Serialization of Non-Legacy Colors


		* Emit "color(", followed by `color-space`, " ", `components`, and then ")".

		* Otherwise, emit `color-space` followed by "(", `components`, and then ")".


		To serialize a non-legacy color `color`:

		* Let `components` be a space-separated list of `color`'s channel values.


		* For each keyword `key` and value `new` in `channel-args`:

		* If `new` is not a number or the special value `none`, throw an error.


		* If the keyword argument `$alpha` is specified in `$args`:

		* If `alpha == none`, throw an error.

		* Set the `channel` with name or index of `key` in `channels` to
		`channel + adjust`, treating values of `none` as `0`.


		* Let `max` be the upper boundary of `channel` in `space`.

		* If `channel > max` or `channel < 0`, throw an error.