[csswg-drafts] [css-color] Order-dependence contradiction in color-mix(),none propagation vs numeric coercion,device-cmyk() colorimetric contradiction (#13906)

heembomj-hub has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color] Order-dependence contradiction in color-mix(),none propagation vs numeric coercion,device-cmyk() colorimetric contradiction ==
https://drafts.csswg.org/css-color-5/
Using claude and chatgpt to find contradictions in this draft document.

1. Order-dependence contradiction in color-mix()
2. none propagation vs numeric coercion
3. device-cmyk() colorimetric contradiction

1.
**Source:** https://drafts.csswg.org/css-color-5/  
**Document date:** Editor's Draft, 2 May 2026  
**Analysis date:** 9 May 2026
---
## 1. `color-mix()` Syntax vs. Described Behavior: Takes "a list of one or more" but the algorithm assumes exactly two
**Location:** §3 Introduction vs. §3.3 Calculating the Result of color-mix
**Contradiction:**
The introductory prose states:
> "the color-mix() function takes **a list of one or more** `<color>` specifications and returns the result of mixing them"
The formal grammar also supports multiple colors:
> `color-mix() = color-mix( <color-interpolation-method>? , [ <color> && <percentage [0,100]>? ]#)`
However, the algorithm in §3.3 is written in terms of a **stack-based pairwise reduction**, where it pops two items at a time. The **mixing is inherently order-dependent** for polar color spaces, and the note explicitly warns:
> "In cylindrical polar color spaces, mixing is **order-dependent** … This algorithm mixes each color in the specified order, mixing the result with the next in the list."
Yet the section header and introductory grammar description say the function takes "a list of one or more" without any warning that order changes the result even for seemingly symmetric inputs. The symmetry examples in §3.2 — such as treating `color-mix(in lch, plum, purple)` and `color-mix(in lch, purple, plum)` as equivalent — directly contradict the order-dependence note in §3.3 for polar spaces like LCH.
**Specific conflicting lines:**
- §3.2: `color-mix(in lch, purple, plum)` and `color-mix(in lch, plum, purple)` are listed as producing identical results.
- §3.3 Note: "In cylindrical polar color spaces, mixing is order-dependent."
LCH is a cylindrical polar color space. The two forms listed as equivalent in §3.2 should, per §3.3, be order-dependent and not guaranteed equivalent.

2.
  (this is number 2 but the contradiction list had a less useful item before this so it says #3)
## 3. `none` Treated as Missing vs. Treated as 0: Contradictory rules in the same section
**Location:** §4.1 Processing Model for Relative Colors and §4.2 Relative Color Syntax
**Contradiction:**
In §4.1, the spec states that missing components (i.e., `none`) are carried forward as missing, consistent with CSS Color 4's interpolation rules:
> "Missing components are handled the same way as with CSS Color 4 § 13.2 Interpolating with Missing Components: the origin colorspace and the relative function colorspace are checked for analogous components which are then carried forward as missing."
But then, at the end of the same section:
> "However, if calculations are done on **missing values**, `none` is treated as **0**."
This creates a contradiction: `none` is simultaneously "carried forward as missing" (preserving its missing nature through the chain) AND "treated as 0" when used in calculations. The spec does not define precisely when a missing component transitions from "missing" to being computed as 0 — specifically, when a user writes `calc(h + 90)` where `h` is `none`, is the result `90` (treating none as 0) or is the result also `none` (carrying it forward)? The document provides the missing-hue gradient example showing carry-forward behavior is desired, but then states `none` = 0 in calculations without resolving which rule takes precedence when a `calc()` is explicitly applied to a `none` value.


3. (same as previous - it found less useful contradictions prior to this, so this is #5)
## 5. `device-cmyk()` Listed as Non-Absolute Color but Used Inside `color-mix()` with Defined Results
**Location:** §2 The `<color>` syntax vs. §3.4 (device-cmyk example)
**Contradiction:**
In §2, the spec defines an "absolute color" and explicitly excludes `device-cmyk()`:
> "`<device-cmyk()>` (which has **no colorimetric basis**)"
It further states that absolute colors are those "not used inside `<color-mix()>` or in relative color syntax."
However, §3.4 contains a full worked example of `device-cmyk()` inside `color-mix()`:
```css
color-mix(in lab, device-cmyk(0.091777 0.043303 0.312816 0.000000) 100%, yellow);
```The spec says the result depends on implementation-specific color profile choices, and even provides two different Lab values from two different ICC profiles as possible results. This directly contradicts the §2 framing that absolute colors are what `color-mix()` works with — `device-cmyk()` is not absolute, yet is used in `color-mix()` and given defined (if implementation-dependent) results. The spec does not reconcile this: it prohibits `device-cmyk()` from being an absolute color and then provides examples treating it as a valid `color-mix()` argument with expected outputs.

Initially found with claude, filtered through chatgpt. Cut and paste by human with advice from chatgpt.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13906 using your GitHub account


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

Received on Sunday, 10 May 2026 09:21:58 UTC