Re: [csswg-drafts] [css-color-4] Achromatic colors converted to hue-ish spaces should treat hue as "missing", not NaN (#6107)

@danburzo 

> Is it worth it to have alpha behave differently with none = 1?
>
> It feels like transparent is a bad default for, let's say, hsl(45deg 50% 50% / none).

The defaults here aren't intended for usage, they're just here to give us *an* answer for what to do when `none` "leaks out" into normal rendering. *None* of the defaults are actually useful, because if they're used the author has made a mistake. As such, I'd prefer to keep this as simple and straightforward as possible and leave everything at zero. (And fwiw, "transparent black" is used elsewhere as a "something's messed up but we need a color/image of *something*", so it's consistent at least.)

> I assume this includes the color() syntax as well, right?

Yup, marking a `color()` as taking some of its channels from the opposing color in a transition makes just as much sense as for any other color function.

---------

@facelessuser 
> I'm curious, what if something like chroma is none is hue treated as undefined?

If a color with a `none` chroma gets displayed, then the `none` gets turned into `0%`, and then the hue becomes powerless. That won't affect rendering directly, but if you then *convert* the color into another space, the hue will indeed become `none` itself and then have the defined effects.

This requires a little work to invoke manually, like `rgb(from hsl(20deg none 50%), r g b)`. (Because the hue turns into `none` as well, *all* of the r/g/b variables becomes missing as well. We haven't carried these edits over to Color 5 to define exactly how infectious `none` works in relative color syntax, but that'll come shortly.)

Again, this is purely an error case, tho. An author should never use `none` directly in a color being displayed, just in colors being transitioned/animated.

> I see that alpha being represented as 1 when undefined is not such a unique proposal and has been implemented by multiple libraries, so I guess this isn't so uncommon.

Note that this isn't behavior for when alpha is *omitted* (that works as you expect - `rgb(255 0 0)` does indeed default its alpha to `100%`), but rather for when alpha is *explicitly marked as "not provided so it can take the value from the other color in a transition"*. Alpha is *never* powerless, so this can never happen automatically; the author has to explicitly mark it, or use relative color syntax to calculate alpha from a color channel that is missing.

-----

@svgeesus 
> In theory they can be any color in an HDR context, whose lightness is greater than media white. In practice people rarely use Lab for HDR, outside academic studies.

So should I leave it as-is (lab lightness >= 100% does *not* render the hue/chroma powerless), then? Or is this  a theoretical ability only, and in practice we should go ahead and define that lightness >= 100% is some variety of "pure white", and leave "colored HDR white" as a something that another color function might handle?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6107#issuecomment-933664408 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 4 October 2021 16:45:49 UTC