Multi-color icon support

[fredvisser]

🤨 Rationale

• Adds opt-in multi‑color (layered) icon support to Nimble components.
• Single‑color icons remain unchanged; severity colors still apply.

👩‍💻 Implementation

• Metadata: icon-metadata.ts supports layers: string[] per Icon<Name> (index maps to cls-1, cls-2, …).

• Generator: Reads TS metadata and, for layered icons, sets data-multicolor and per‑layer CSS vars --ni-nimble-icon-layer-N-color using design tokens.

• Styles: Severity overrides apply only when data-multicolor is absent. Layer fills are defined for cls-1 … cls-6.

• Updated guidance in CONTRIBUTING.md (single flow for single‑ and multi‑color icons).

• Updated nimble-icon-circle-partial-broken to verify behavior. TODO: Probably need to update the theme colors.

🧪 Testing

• Manual storybook review

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[jattasNI]

This section is too verbose. I didn't read all of it but a few items that stuck out:

• we don't normally provide things like "common pitfalls"
• we shouldn't have optional testing suggestions, we should say what's necessary and nothing more
• if we're going to refer to other documentation (see last line) we should link to it
• it's hard to tell without a concrete example but I think a lot of it is implementation detail, not what the person adding the icon needs to know

[fredvisser]

Rewrote and merged with the existing instructions — much more concise

[rajsite]

I'm skeptical about the implementation direction of the PR. API-wise as custom element authors we shouldn't be using data attributes, those are for users for user use-cases.

And I don't think the single attribute handles the use cases I've seen for multicolor icons. I think there are both multi-tone icons (which need multi theme aware colors configured) and like multi-tone configurable icons (icons that have like a configuration api to show both theme aware tones and have an api for configuring part of an icon like a separate status).

Haven't thought it through completely but maybe these icons with extra features should actually be separate files that extend Icon. i.e. they are treated more like web components and can have additional capabilities / apis instead of wedging everything into an Icon class and overly generic generated code behaviors.

[fredvisser]

we shouldn't be using data attributes, those are for users for user use-cases.

Is that right? Copilot tells me that:

Use data-attributes (data-*) when:

• You are storing custom, private, or application-specific data on standard HTML elements.
• The attribute is not part of the HTML specification or a Web Component’s published API.

…and that's the rationale here - data-multicolor is not intended to part of the published API. Is there an alternative approach?

I talked it through with Brandon, and we don't currently have use cases for the multi-color configurable icons, so I have no interest in supporting it at this time.

[rajsite]

Is there an alternative approach?

Did you ask copilot? Would be interesting what it finds. Maybe I'll keep it secret and you tell me. Yes there are alternative approaches to storing state on custom elements to data attributes. They are used ubiquitously in practically every web component.

Also ask it for an approach that does not rely on code generation. It can look through PR history where lots of effort was put in to avoid excessive code generation. Another hint is we have patterns for "extending" components for specialized behavior. Goal is pretty much all source should be in source, almost none in build scripts.

There is probably also an exercise needed in how one opens up a PR proposing larger pattern changes vs incremental feature changes designed by AI.

Edit: the above is framed as an exploration of how to try and get the AI to generate code and patterns expected in nimble. That also may not be the goal of your questions? I'm not actually sure what the intentions of this PR is. Try and make code that owners would happily approve? Then we need more refinement because the direction here seems out of line of normal in nimble and my hunch is that it is unnecessary done so. Maybe we would want to encourage asking in the issue about implementation directions before starting or opening PRs in draft to get input in direction. Use AI to generate anything that seems functional and accept that? That's the intention of the ok packages, not core nimble.