-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
none
should be turned into null
, not NaN
#409
Comments
So now we’ve announced that the change is coming.
|
So, I'm curious, are Mathematically, they will not behave the same. I guess it will be easier to miss when |
The more I think about it the more questions I have. If both are preserved and you are interpolating between both NaN and null, which is returned, NaN or null? This seems like an unfortunate complication in CSS colors. It doesn't seem to provide anything extra, only confusion. It's a shame Is there value in preserving both NaN and null in colors? Especially if they are meant to behave the same? I guess I would opt for a solution that normalizes these two values. I'm not sure how having both null and NaN helps users. |
Nope, they mean different things. I was only suggesting they behave identically in v0.6.0 as a way to ease the transition.
These are excellent questions for CSS Color! Pinging the other editors, @svgeesus @tabatkins
I believe @tabatkins has strong opinions on why that would have been a mistake, and I hope he is willing to explain or point to his comments on the matter (FWIW Chris and I had your view and he convinced us 😬 )
They are not meant to behave the same, nor do they represent the same thing, see above. |
The representation difference I get. One is number thing and maybe stuff like So, functionality-wise, Does Are NaNs no longer resolved to a real value at any time? The color spec doesn't speak to any of this currently. As far as Im aware, it still speaks to NaNs representing undefined coordinates. |
I had remembered the discussion about using NaN vs none and found it here: w3c/csswg-drafts#6107. I think it didn't bother me at the time because, functionality-wise, the end result was going to be the same, or at least seemed to be. It seemed more of a syntax issue difference making clear the difference of what At the time, there was no |
Okay, I did find this in the Color 5 spec:
I guess this explains the treatment of undefined as a null. So, I guess that answers my question. Undefined is no longer infectious (which is a shame because it made sense), but I get its context when looking at CSS. And NaN just behaves as NaN. So this change will be a surprising change in Color.js. |
It's exactly the opposite actually: When doing math (e.g.
Precisely! That's why it's important not to do conversions we don't need (such as converting colors that are in-gamut in a GMA that doesn't modify in-gamut colors).
I would imagine that interpolating
I don't understand what you're saying here, could you elaborate a bit more? Why is it a shame that |
Undefined is no longer Before, undefined operated as > a = NaN
NaN
> a + 3
NaN
> a = 0
0
> a + 3
3 Now it is null, and we will quite literally be using null. It is uniquely different, and has its own identity up until you do anything with it, then it is zero (at least in most languages). This describes the behavior in the spec and it quite literally mimics how > a = null
null
> a + 3
3 It's a change in concept and any library that implemented the As a side note, I've personally found the very specific behavior of undefined == 0 (whether mimicking NaN or null) to sometimes be lacking in the user experience, from a general purpose color library standpoint. Consider below. >>> Color('black').convert('acescc')
color(--acescc -0.35845 -0.35845 -0.35845 / 1)
>>> Color('black').convert('acescct')
color(--acescct 0.07291 0.07291 0.07291 / 1) Neither of these two spaces define black with zeros , not that undefined has to resolve to black, per se, but if we apply them, we get out of gamut results for acescct. Not very helpful. >>> Color('acescct', [0, 0, 0]).convert('srgb')
color(srgb -0.07781 -0.07781 -0.07781 / 1) These cases are rare, but this inflexibility can break in certain aspects. I initially had this issue with spaces like HCT and JzCzhz, has zero chroma and zero hue no longer mean white, gray, etc. (at least not pure white and gray). At least with these spaces, I think I'm starting to come to the realization that they are accounting for adapting luminance and background luminance, and when you do this, the achromatic colors appear different than pure white, pure gray, etc. If you "discount the luminance", you get a more traditional achromatic response of pure achromatics. So maybe the concept of zero chroma and zero hue must be pure achromatic was flawed initially, at least when looking at JzCzhz, CAM16, ZCAM, etc. |
I may be incorrectly lumping JzCzhz in with CAM16 and ZCAM, it has a similar achromatic response, but maybe its response is simply based off of less accurate matrices 🤷🏻. |
The arguments against lumping NaN with none in CSS were in w3c/csswg-drafts#6107, especially this comment. In short: while NaN can serve as a reasonable sentinel value in many situations (because it's not part of the normal value space), you don't actually want author-produced NaNs (which come from math errors) to trigger this behavior. CSS can easily avoid the sentinel value issue and just use a different value (a keyword, in this case), thus treating any NaNs that are accidentally fed into the functions as an error case. However, @LeaVerou, note that the color functions never see a NaN. A NaN gets censored into |
Ah, that is correct, we can't directly use NaN or Infinity in colors as things are currently, not as far as CSS syntax is concerned. They would have to be wrapped in So really, assuming Color.js really prefers nulls in general, it could just convert NaNs to null and call it a day. If a change must be made, I imagine this would be the least breaking. So what this really boils down to is whether color.js prefers NaN behavior or null behavior. |
@tabatkins I thought users can also directly specify @facelessuser Even if |
Yep, that is certainly true. |
Putting my opinions aside, I think I understand the situation and how the behavior will change now, and I now understand the reasoning behind it. Because this is still a < 1.0 version, and I'd hate to see the overhead required to validate every value on every set, I'm kind of leaning more towards just making the change, with a bold note in the changelog of the breaking change. |
Nope, they can say |
This issue is a blocker for v0.6.0 so I’m keen to resolve it ASAP. Thinking back to…
It seems like there was no resolution? If so, I think this what I’ll do:
|
Also don't clamp alpha if it's none, in preparation for #409
In preparation for #409 but also allows removing code for this in the Color constructor
This allows reading metadata without having to make the values objects, and is the *only* way to attach metadata to null (see #409)
Besides being more semantically correct, it paves the way for #409
Should NaN be converted to 0 when converting between colors or is it left as NaN? |
I think it's fine to leave it as NaN, but feel free to open another issue to discuss that. |
This was a resolution in a past breakout with @svgeesus but I’m opening this so we can track it.
Color.js currently uses
NaN
values to represent CSSnone
(e.g. for achromatic colors).However, CSS also now has a
NaN
value, which is currently impossible to represent in Color.js in a distinct way.Therefore, In the next non-minor version, we will start using
null
to representnone
.Authors can actually handle both, by detecting which value is used via:
They can then use
NONE_COORD
instead of a hardcodedNaN
so that nothing breaks in their code once they upgrade.I therefore plan to announce this change in the release notes for v.0.5.0 and recommend they handle it that way to prepare.
The text was updated successfully, but these errors were encountered: