Semantic neutral muted rest fill equals canvas — filled components become invisible

[pomfrida]

Found during the Chip migration to the semantic interactive tokens (#5225, comment).

background-interactive-neutral-muted-default resolves to neutral-1 — the same value as --eds-background-canvas. A component that uses the muted trio as a filled resting surface therefore becomes invisible against the canvas in light mode: the resting neutral default-variant Chip shows only its text, no pill.

The other tones don't have this problem (their muted rest is step 2, visibly tinted), and Button doesn't hit it because ghost is transparent at rest — the muted trio is only used for hover/pressed there. Chip is the first component to use *-muted-default as an always-visible fill.

Question for design: is neutral-1 intended as the resting value for filled muted surfaces, or should background-interactive-neutral-muted-default sit one step up (making the neutral trio 2/3/4 like the other tones)? Related to the resting-shade discussion in #5282, but this is a light-mode semantic-value question, not a scale bug.

Chip (#5225) holds on this — the neutral default variant is the component's default appearance, so an invisible resting state blocks merge under the beta quality bar.

[claude]

These issues may be related:

• Dark palette scales are non-monotonic: step 6 duplicates step 3 #5282 — Dark palette scales are non-monotonic: step 6 duplicates step 3 (open): from the same Chip migration finding, and its "Impact" section names the mirror-image problem — the background.interactive.*.muted ladders sitting almost on the canvas at their default step in dark. This issue is the light-mode semantic-value counterpart, and both point at the same resting-shade decision.
• Semantic interactive tokens are missing success and info tones #5283 — Semantic interactive tokens are missing success and info tones (open): also filed from the Chip migration against the same *-interactive-* groups, and explicitly asks for the resting-shade question to be resolved in the same Tokens Studio round so components can drop raw-shade workarounds.
• [Chip] Migrate to new beta colour tokens #5223 — [Chip] Migrate to new beta colour tokens (open): the migration this issue blocks; its DoD includes flagging semantic-layer gaps as learnings.
• Input field not visible on white backgrounds, need alternative styling #4668 — Input field not visible on white backgrounds, need alternative styling (closed as completed): same symptom class in the previous token generation — a component background token resolving to the canvas value, leaving the control invisible on white. Its proposed remedy (a dedicated fill token rather than reusing canvas, plus a subtle resting border) may be useful precedent for the design answer here.

This comment was generated by an LLM and may be inaccurate. Please verify that the linked issues are actually relevant.