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

> I still think that handling NaN as Infinity is completely inconsistent with any other language that uses NaN, as well as with IEEE 754, but if we don't use it here, perhaps the effects of that will be more limited.

Other computer languages are allowed to throw errors when you pass in bad input, and so that's usually what happens when someone accidentally produces a NaN. CSS can't do that, so we work with the abilities we have: making it *probably obvious* that there's an error, by causing something to likely blow up with an infinity.

(It's uncommon, but we do similar things in other spots in CSS when a value is parsed as valid, but ends up being meaningless or an error in context; we choose an arbitrary answer this is easy to define and implement, and hopefully makes it obvious to the author that something has gone wrong. See, for example, referring to a non-existent grid line name in `grid-row`; the reference is instead interpreted as being the first implicit grid line. That's not because it's what we think they meant, it's because we need to do *something*, and that behavior is likely to be obviously wrong, since referring to a line name implies there's an explicit grid, and the item will get pushed outside of that.)

> how would this "missing" value serialize in Typed OM and the like?

Assuming we *did* allow a "missing hue" color to be exposed to the author (rather than just being a spec-internal concept that produces a normal hued color in the values that are author-exposed), then it would just mean that the `.hue` attribute's type would be `(CSSKeywordValue or CSSNumericValue)`, with checks to ensure that you can only pass the "missing" keyword. Very straightforward, not complex at all.

(Note that the TypedOM repr gives the hue as a TypedOM numeric object, because it's an angle which can have multiple units, and might be a math function. This gives us a lot of flexibility in the value, versus more JS-only APIs that would just use `double`.)

--------
>> Are you really wanting to argue that hsl(calc(0deg/0), ...) should be treated as an achromatic color? Like, that's intentionally something you desire for this function?
>
> No. That is your model of "the only way NaN can occur", not mine.

I apologize, I might not have made it clear enough why I was asking the specific question. This isn't a gotcha, or rhetorical, I was really wanting an answer from you, because it's important to how this question gets resolved. *If* the `<hue>` argument can be NaN, then the source of the NaN doesn't matter - whether it's produced due to a browser's automatic colorspace conversion or an author explicitly writing it, a NaN is a NaN and will give the same behavior.

So, given that, I re-ask my question: is `hsl(calc(0deg/0), ...)` something you intentionally want to support as defining an achromatic color? If it is, you can try to sell that to the WG, but I don't think you'll succeed. If you *aren't* intending that to be valid and mean an achromatic color, then "hue can be NaN" isn't what you actually want.

> As I already said:

I apologize, but I don't know what you're trying to say here. Your terseness is really making it hard to figure out the points you're trying to make. :(

>> Sure, but all such conversions are censored away into a color with a hue before authors see it, right?
>
> You keep stating this. No. Why would it? The spec is already very clear that some cylindrical polar color representations have an undefined hue. You seem to believe that it is censored away into +infinity which then becomes, I dunno, 360?

Again, I asked that question deliberately. In what situation, precisely, is a color with undefined hue exposed to the author, in such a way that they can actually see the "undefinedness" represented in the value?  I pointed to all the places where undefined hue seems to be capable of occurring, and as far as I can tell, by the time a value actually gets out to the author, that value always has a defined hue. 

In the spec, undefined hue *appears* to happen *solely* due to an achromatic hueless color being converted into a hueful space for the purpose of interpolating or mixing, and then the interpolation rules cause it to be *treated* as having a particular hue (that of the other color) at all points. Am I wrong? Does undefined hue happen at other times, in a way that would be exposed to the author by the OM? If so, where, and can you give me some sample code that would show it?

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


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

Received on Monday, 22 March 2021 18:16:04 UTC