none 与 0 - 在 CSS 颜色函数中，它们什么时候等价，什么时候不等价？

Question

我试图通过在 CodePen 中创建一些可视化示例来理解 CSS 颜色函数中的

none

与

0

。我目前的理解是，至少在实践中，

none

和

0

是等价的，除非在不同空间的颜色之间进行插值。当设置单一静态颜色的值时，无颜色和零应该在屏幕上产生相同的结果。请参阅 MDN 文档此处。

但我至少看到一个例外，其中零输出颜色，无输出黑色。这两个值在屏幕上产生明显不同的结果：

lch(none 90 0)

vs

lch(0 90 0)

div {
  display:flex;
  flex-grow:1;
  height:50px;
}

<div>
  <div style="background-color:lch(none 90 90);"></div>
  <div style="background-color:lch(0 90 90);"></div>
</div>
<div>
  <div style="background-color:lab(none 90 90);"></div>
  <div style="background-color:lab(0 90 90);"></div>
</div>

与

lab()

相同，共享亮度参数。但它不适用于

lch()

中的色调，至少不适用于 Chrome。在 Firefox 中，将 Hue 设置为 None 会将输出设置为黑色，因此其中之一是错误的...

此示例表明，除了在两种不同颜色之间进行插值之外，无和零是不同的。有人可以澄清这一点，或者给我指出一些为像我这样的傻瓜解释它的文档吗？

此外，在两种颜色之间进行插值会产生不同结果的一些具体示例：

none

与

0

？我使用

linear-gradient()

作为插值器进行测试，但我很难找到

none

与

0

在线性梯度插值中产生差异的情况。

编辑：发布此问题后，我发现示例片段在 Chrome 和 Firefox 中显示不同 - 视觉上的左侧和右侧（CSS 中的

none

与 CSS 中的

0

）在两个浏览器之间翻转。

Answer 1

在这种情况下 Firefox 是不正确的；

lch(0% 90 90)

应根据 CSS 规范 生成黑色。您还可以看到 Firefox 和 Safari 未能通过应该生成黑色方块的 LCH 测试，而是生成红色。

我不清楚浏览器在使用 none 时应该做什么

，但是 

lch(none 90 90)

 生成红色是可以理解的：

• LCH [0, 90, 90]

   与 D50 参考白色是 

  RGB [42, -5, -73]
由于尚未明确指定存在“0% 亮度”（即黑色），因此它只是固定到
• RGB [42, 0, 0]

   或 

  #2a0000
同样，带有 D50 参考白色的
• LAB [0, 90, 90]

   是 

  RGB [97, -50, -72]

  ，变成 

  RGB [97, 0, 0]

   或 

  #610000

出于某种原因，Firefox 将

none

 视为 

“无亮度”，而不是 “未指定”，并忽略“0% 亮度”应被视为黑色。

Answer 2

我在 github/color.js 上展开了讨论，看看那里是否有人可以提供更明确的答案：

https://github.com/color-js/color.js/discussions/495

总结一下那里的回应：

a) 是的，对于单色值，

none

 和 

0

 应在屏幕上产生相同的结果。

b) Firefox 错误地处理

none

（Bugzilla 上还没有人回复我的 bug）。

c）Chrome 和 Safari 使用裁剪（又名夹紧）而不是色域映射，并且我问题中的片段根本不应该显示黑色。 Safari 是正确的，但 Chrome 将

0

 显示为黑色，这意味着它与 

none

 不匹配，这意味着它不正确。所以不，并非所有矩形都应该是黑色的，但它们的左侧和右侧都应该相同，即 

none

 与 

0

 相同。 Chrome 有两个与此相关的“已修复”问题（

https://issues.chromium.org/issues/40265669 和 https://issues.chromium.org/issues/40262403），我之前已对此发表过评论提交新错误。

如果您想深入了解 CSS 对亮度的处理，请参阅此 w3c/csswg-drafts 讨论：

https://github.com/w3c/csswg-drafts/issues/8794

感谢@wacton 和@gre_gor 的参与。我不会将任何答案标记为“已接受”，至少目前还没有。对于浏览器来说，这是混乱的、相对较新的东西，比我根据可用文档预期的更混乱。