feat(c4): render elements in the c4model.com outline style - #7991
feat(c4): render elements in the c4model.com outline style#7991filipsajdak wants to merge 1 commit into
Conversation
✅ Deploy Preview for mermaid-js ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
🦋 Changeset detectedLatest commit: de8e745 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughC4 outline elements now use theme surfaces for fills. Stylesheets generate contrast-adjusted identity colors for borders and labels. Explicit element color overrides remain authoritative. C4 rendering and snapshot coverage use the updated styling model. ChangesC4 outline styling
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related issues
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@mermaid-js/examples
mermaid
@mermaid-js/layout-elk
@mermaid-js/layout-tidy-tree
@mermaid-js/mermaid-zenuml
@mermaid-js/parser
@mermaid-js/tiny
commit: |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #7991 +/- ##
===========================================
- Coverage 77.61% 77.56% -0.05%
===========================================
Files 567 573 +6
Lines 74906 75329 +423
Branches 14619 14703 +84
===========================================
+ Hits 58141 58432 +291
- Misses 15768 15893 +125
- Partials 997 1004 +7
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/mermaid/src/diagrams/c4/styles.js`:
- Around line 20-46: Update elementFontStyles to avoid constructing
CSSStyleSheet directly, using a document-created style element’s sheet instead
so it works in older browsers and jsdom. Insert and serialize the rules through
that sheet as currently done, then remove the temporary style element after
generating the returned CSS text while preserving the existing font-style
behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 452dc016-9bc7-4eea-965c-7f70b290a182
📒 Files selected for processing (23)
.changeset/c4-outline-theme.md.changeset/c4-unified-shapes.md.changeset/person-shape.md.cspell/mermaid-terms.txtcypress/integration/rendering/c4/c4-characterization.spec.jscypress/integration/rendering/c4/c4.spec.jscypress/integration/rendering/newShapes.spec.tsdocs/config/setup/mermaid/interfaces/LayoutData.mddocs/syntax/c4.mddocs/syntax/flowchart.mdpackages/mermaid/scripts/docs.spec.tspackages/mermaid/src/diagrams/c4/c4Renderer.tspackages/mermaid/src/diagrams/c4/c4ShapeAdapter.tspackages/mermaid/src/diagrams/c4/styles.jspackages/mermaid/src/diagrams/c4/svgDraw.tspackages/mermaid/src/docs/syntax/c4.mdpackages/mermaid/src/rendering-util/rendering-elements/shapes.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/c4LabelHelper.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/cylinder.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/person.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/tiltedCylinder.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/util.tspackages/mermaid/src/rendering-util/types.ts
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
caef72e to
17f0e9f
Compare
|
Re-pointed onto the new #7842 base. #7842 was approved and its history tidied to 9 commits (38 before), and this branch was sitting on an older point of it - missing its last 5 commits - as well as The outline change is still the single commit it was; it 3-way merged onto the new base with no conflicts, and the delta is byte-identical to before (3 files, +35/-14): Diffing the old delta against the new one produces no output, so rebasing changed nothing about what this PR proposes. Local checks on the new tip: c4 unit suite 126/126, For context, since this PR has not been reviewed yet: it reintroduces the c4model.com outline look (white fill, identity colour as border and text) that was deliberately reverted out of #7842 to keep the legacy element colour configuration working. The open question in the description still stands - whether these colours should come from theme variables instead, which overlaps #7868. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
packages/mermaid/src/rendering-util/rendering-elements/shapes/util.ts (1)
18-21: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReserve
stereotype-based label routing for C4.
stereotypeis on the sharedBaseNodetype, while only C4 adapters populate it; any diagram that adds it will bypass the standard label path (HTML labels, markdown,centerLabel, icon/img background). Add an explicit routing flag, or callc4LabelHelperdirectly from the C4 label paths.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/mermaid/src/rendering-util/rendering-elements/shapes/util.ts` around lines 18 - 21, Restrict the stereotype-based routing in the visible label-selection logic to C4 diagrams instead of checking the shared BaseNode.stereotype field alone. Add or reuse an explicit C4 routing indicator, or move the c4LabelHelper call into the C4-specific label paths, while preserving the standard label handling for non-C4 nodes.packages/mermaid/src/diagrams/c4/c4ShapeAdapter.ts (1)
154-161: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winHardcoded
fill:#ffffff`` will read poorly on dark themes.The outline fill is a literal white while everything else derives from config/theme. As already noted in the PR description, sourcing this (and the darkened identity colour) from theme variables would keep dark themes legible; worth coordinating with the theme-variable work rather than shipping the literal.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/mermaid/src/diagrams/c4/c4ShapeAdapter.ts` around lines 154 - 161, The elementCssStyles function hardcodes a white fill, which is not theme-aware. Replace the literal fill value with the appropriate configured/theme-derived variable, and coordinate the identity color passed to ensureReadable so both fill and darkened identity styling remain legible across light and dark themes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@cypress/integration/rendering/c4/c4-characterization.spec.js`:
- Around line 265-268: Update the shape assertions in the C4 rendering test to
target the individual nodes by their labels instead of using aggregate .node
counts. Assert that the cylinder node contains its expected path structure and
the folder node contains the expected rectangle structure, preserving the
existing override behavior.
---
Nitpick comments:
In `@packages/mermaid/src/diagrams/c4/c4ShapeAdapter.ts`:
- Around line 154-161: The elementCssStyles function hardcodes a white fill,
which is not theme-aware. Replace the literal fill value with the appropriate
configured/theme-derived variable, and coordinate the identity color passed to
ensureReadable so both fill and darkened identity styling remain legible across
light and dark themes.
In `@packages/mermaid/src/rendering-util/rendering-elements/shapes/util.ts`:
- Around line 18-21: Restrict the stereotype-based routing in the visible
label-selection logic to C4 diagrams instead of checking the shared
BaseNode.stereotype field alone. Add or reuse an explicit C4 routing indicator,
or move the c4LabelHelper call into the C4-specific label paths, while
preserving the standard label handling for non-C4 nodes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 87037f4b-36c3-4ef7-98a3-9d4bb61e8ae0
📒 Files selected for processing (24)
.changeset/c4-outline-theme.md.changeset/c4-unified-shapes.md.changeset/person-shape.md.cspell/mermaid-terms.txtcypress/integration/rendering/c4/c4-characterization.spec.jscypress/integration/rendering/c4/c4.spec.jscypress/integration/rendering/newShapes.spec.tsdocs/config/setup/mermaid/interfaces/LayoutData.mddocs/syntax/c4.mddocs/syntax/flowchart.mdpackages/mermaid/scripts/docs.spec.tspackages/mermaid/src/diagrams/c4/c4Renderer.tspackages/mermaid/src/diagrams/c4/c4ShapeAdapter.tspackages/mermaid/src/diagrams/c4/c4Types.tspackages/mermaid/src/diagrams/c4/styles.jspackages/mermaid/src/diagrams/c4/svgDraw.tspackages/mermaid/src/docs/syntax/c4.mdpackages/mermaid/src/rendering-util/rendering-elements/shapes.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/c4LabelHelper.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/cylinder.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/person.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/tiltedCylinder.tspackages/mermaid/src/rendering-util/rendering-elements/shapes/util.tspackages/mermaid/src/rendering-util/types.ts
🚧 Files skipped from review as they are similar to previous changes (8)
- .changeset/person-shape.md
- .changeset/c4-outline-theme.md
- .cspell/mermaid-terms.txt
- docs/config/setup/mermaid/interfaces/LayoutData.md
- docs/syntax/c4.md
- packages/mermaid/src/docs/syntax/c4.md
- packages/mermaid/scripts/docs.spec.ts
- packages/mermaid/src/rendering-util/types.ts
|
Thanks @coderabbitai - both nitpicks addressed here rather than in code, with reasons.
Worth noting the premise is only half right: any node carrying a
I have made that consequence explicit in the PR description so the trade-off is visible rather than implied. |
|
Tip For best results, initiate chat on the files or code changes.
I’m withdrawing both findings. 🐇💭 ✏️ Learnings added
You are interacting with an AI system. |
5c3416c to
c05a376
Compare
|
Rebased onto current The tree is byte-identical to the previous head - the commit was rebuilt from that exact tree rather than replayed, and Still 3 files, +35/-14, and the open question in the description stands: whether the outline fill and identity colour should be sourced from theme variables (overlapping #7868) before this merges. |
|
No human review yet on this one either. Standalone since #7842 merged: 3 files, +35/-14. There is a genuine open question here that needs a maintainer opinion rather than more work from me: whether the light fill and identity colour should come from theme variables (which overlaps #7868) or stay literal for now. As it stands the fill is a literal white, which reads poorly on dark themes. If you would rather this waited for the theme work, it is cheap to park - it is deliberately the most droppable PR in the set. The Full stack status: #7849 (comment) |
c05a376 to
0a56256
Compare
|
Force-pushed to remove the This was raised in review on #7859, citing the project's own rule against tagging commits as AI-authored. Since this repo merges rather than squashes, the message would land on Nothing else about the PR moved: same single commit, same diff, same tests. |
knsv-bot
left a comment
knsv-bot
left a comment
There was a problem hiding this comment.
[sisyphus-bot]
Thanks for splitting this out, @filipsajdak — separating the visual redesign from the shape migration was exactly the right call, and it paid off: the diff is 3 files and the Argos comparison is precisely the legacy-colours → outline change, nothing else. That is a genuinely well-constructed PR.
Flagging this as "changes requested" mostly because you asked us a direct question that should be answered before this merges — your own words — plus one behaviour change I don't think was intentional. The direction is right; none of this is rework.
What's working well
🎉 The split itself. Following through on @aloisklink's review by rebasing the redesign onto merged #7842 rather than arguing for the bundle is the kind of thing that makes review cheap for everyone downstream.
🎉 The characterization suite from #7842 is doing its job here. c4-characterization.spec.js covers every element variant, so this PR gets a meaningful visual diff for free. That's the payoff for having written it.
🎉 ensureReadable guards the NaN path (c4ShapeAdapter.ts:140-142). I verified against the real palette — #08427B, #686868, #1168BD all pass through untouched (L ≤ 0.42 already), and only the lighter entries move: #999999 → #6b6b6b, #85BBF0 → #176cbf. Sensible, minimal behaviour on the defaults.
🎉 The PR description states the cost of deferring instead of quietly leaving it. More PRs should do this.
Things to address
🟡 [important] <type>_border_color is now silently ignored
c4ShapeAdapter.ts:154-171 — the stroke used to come from the <type>_border_color config entry. It now comes from <type>_bg_color (darkened), and _border_color is never read at all.
Those keys are still public config: 40 of them in config.schema.yaml:757-877, each with its own default distinct from the bg colour (person_border_color: #073B6F, system_border_color: #3C7FC0, external_person_border_color: #8A8A8A). Anyone who set one today gets it dropped with no warning and no error.
I don't think you can detect "user customised this" at runtime — config always carries the default — so honouring it conditionally isn't really available. That makes it a documentation and changeset problem rather than a code one:
- Add a line to
.changeset/c4-outline-theme.mdsaying<type>_border_colorno longer affects rendering, so it lands in the release notes. - Worth a maintainer opinion on whether the keys should be marked deprecated in the schema, or kept as a way to override the derived stroke.
Happy to be told this is fine as-is — but it should be a decision on the record rather than a side effect.
🟡 [important] The hardcoded white fill — answering your open question
c4ShapeAdapter.ts:156 (const styles: string[] = ['fill:#ffffff']). You're right that this leaves white boxes on dark themes, and I don't think you need to wait for #7868 to fix it.
personBkg and personBorder already exist as theme variables in every theme, dark included (theme-default.js:120-121, theme-dark.js:88-89), and c4/styles.js already consumes options.personBkg for the .person rule. mainBkg is likewise what userNodeOverrides falls back to for node fills across the codebase.
So the shape that avoids the dark-theme regression without blocking on the theme-variable work:
- Move the base fill out of the inline per-element styles and into
styles.jsas a.c4-shaperule driven by a theme variable (options.personBkg/mainBkg). - Keep emitting an inline
fill:only for an explicit$bgColoroverride.
That ordering matters and works in your favour: an inline style attribute beats a stylesheet rule, so dropping the unconditional inline white is what lets the theme value apply while $bgColor still wins. Dark themes then get a dark fill for free, and this stops being coupled to #7868 at all.
If you'd rather sequence it after #7868, that's a defensible call — but then I'd want the changeset to say dark themes are knowingly not supported yet.
🟡 [important] Test coverage for the changed code
The "126/126 C4 unit tests passed" figure is all parser tests (parser/c4*.spec.ts) — there is no c4ShapeAdapter.spec.ts, so elementCssStyles and ensureReadable have no direct coverage, and this PR could not have failed a unit test.
Two concrete gaps:
ensureReadableis a purestring → stringfunction — ideal unit test. A handful of cases (already-dark passthrough, the#999999clamp, the NaN passthrough) would pin the behaviour cheaply.- No theme coverage in the C4 Cypress specs at all — I grepped both
c4.spec.jsandc4-characterization.spec.jsand neither sets a theme. This is the one that matters: Argos will show a clean, correct-looking default-theme diff while the dark-theme regression above stays completely invisible. A single dark-themeimgSnapshotTestwould make the tradeoff visible instead of theoretical.
Security
Ran a dedicated XSS/injection pass over the diff. No new injection surface — the old code already interpolated $bgColor/$borderColor/$fontColor into the same three properties, and these values reach the DOM via .attr('style', …) (drawRect.ts:57, person.ts:53, util.ts:35), never a <style> element or innerHTML. useHtmlLabels: false keeps labels on the SVG <text> path. Routing the palette colour through hsl().formatHex() actually narrows it to #rrggbb. DOMPurify is untouched.
One pre-existing item, explicitly out of scope for this PR, noted so it isn't lost: c4Db.ts:504-527 (updateElStyle) stores $bgColor/$borderColor/$fontColor verbatim without sanitizeText, and styles2Map splits on the first : only — so $fontColor="red;font-family:x" smuggles an extra declaration into the style attribute. Bounded to CSS-in-an-attribute (no script execution), but worth a separate issue.
Nits
🟢 c4ShapeAdapter.ts:176 — the buildC4Node JSDoc still says the <type>_bg_color/<type>_border_color palette "drives the fill and border". After this change _bg_color drives border and text, and _border_color drives nothing. You updated the elementCssStyles doc comment right above it; this one got left behind.
🟢 ensureReadable (c4ShapeAdapter.ts:139-146) promises a bit more than it delivers — it clamps HSL lightness, which isn't perceptual luminance. #ffff00 → #d6d600, roughly 1.5:1 against white. The defaults are all blues and greys so nothing is affected today, but a custom yellow/cyan palette still lands unreadable. Either a luminance-based check (khroma exposes luminance/contrast) or a slightly humbler name would match the behaviour.
🟢 The double fill: (:156 then :163) is correct — I traced it through compileStyles → styles2Map, which is a Map, so last-write-wins, and the rough path reads the same map via stylesMap.get('fill'). But it depends on non-obvious semantics in shared rendering-util/ code. A short comment on :156 noting the override relies on last-wins would protect it.
💡 The codebase's colour-manipulation convention is khroma (themes/*.js, kanban/styles.ts); there's no other hsl import from d3 in src/. d3 is already a dependency so this isn't wrong, just off the beaten path — and khroma would give you the luminance check in the same move.
To be clear about the ask: items 2 and 3 are really one decision (theme variable + a dark-theme snapshot to prove it), and item 1 is a sentence in the changeset. Happy to look again quickly once you've picked a direction on the fill — and if you'd rather defer the theme work to after #7868, say so and I think this can go in with the changeset updated to match. Thanks again for the clean slice.
|
Hej Filip! Your contributions have really stood out, and we appreciate the care and momentum you’ve brought to the project. If you’d be interested, we’d be happy to talk about ways for you to be involved more closely. |
|
Hi Knut! At the moment I am focusing on bringing full support for C4 diagrams that I need to build my architecture documentation (arc42). I am open to discuss any ideas that you have in mind. |
0d42c7a to
2db6952
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/mermaid/src/diagrams/c4/c4Colors.ts`:
- Around line 30-40: The contrast adjustment logic must retry from the original
color using the opposite shift direction when the initial 12-step pass remains
below CONTRAST_TARGET. Update the relevant readable-color function around the
shift/readable loop, preserving the bounded behavior, and add a regression
assertion that readableOn('`#08427B`', '`#888888`') achieves at least 4.5:1
contrast.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 18accfd5-6c2a-4469-9941-b7afea9364d7
📒 Files selected for processing (8)
.changeset/c4-outline-theme.mdcypress/integration/rendering/c4/c4.spec.jspackages/mermaid/src/diagrams/c4/c4Colors.spec.tspackages/mermaid/src/diagrams/c4/c4Colors.tspackages/mermaid/src/diagrams/c4/c4Renderer.tspackages/mermaid/src/diagrams/c4/c4ShapeAdapter.tspackages/mermaid/src/diagrams/c4/styles.jspackages/mermaid/src/diagrams/c4/styles.spec.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/mermaid/src/diagrams/c4/c4ShapeAdapter.ts
|
Thank you - and thank you for answering the open question instead of leaving it to me. You were right that this did not need to wait for #7868, and following the theme-variable pointer turned up something I had not seen: the change as you described it would have shipped a bug, so it grew a little beyond the three items. 🟡 The white fill - taken, and the reason it needed more than moving the fillYour reasoning about the mechanism holds exactly. What that surfaced: The clamp also could not be fixed where it was: So the palette-derived colours now come from the stylesheet, which is the one place with both
One caveat on tooling, in case it saves you time later: khroma's On the fill variable: I used While in there: the 🟡
|
An element sits on the theme's surface colour with its identity colour as the border and the label text, as on c4model.com, rather than a solid palette fill with white text. The identity colour is the element's `<type>_bg_color` palette entry shifted until it reads against that surface, so a dark theme gets a light identity on a dark body instead of a dark one on a dark one. The palette-derived colours are emitted by the stylesheet, keyed on the `c4-<type>` class the shape adapter sets, because that is where the theme variables are available. `UpdateElementStyle`'s `$bgColor`, `$borderColor` and `$fontColor` are still emitted inline on the node and so continue to take precedence over all of it. `<type>_border_color` no longer affects rendering: the border is the identity colour derived from `<type>_bg_color`.
2db6952 to
de8e745
Compare
|
Filed the element-colour validation item as #8057, as promised. Worth flagging one thing, because I nearly filed it wrong. I had written down the mechanism as " What is actually true, and what the issue says instead:
The suggested fix is the That leaves the strengthened characterization assertions as the only thing still owed from this review. Both blockers have merged, so I will do them with the |
3 participants
Description
The C4 shape-migration PR #7842 originally introduced the c4model.com outline look (a light fill with the element's identity colour as the border and text). During review, @aloisklink pointed out that bundling that visual redesign into the shapes-migration PR made a breaking change to the existing C4 colour config and muddied the visual-regression review. So #7842 keeps the existing colours, and this PR carries the outline redesign on its own.
An element now sits on the theme's surface colour with its identity colour as the border and the label text. The identity colour is the element's
<type>_bg_colorpalette entry, shifted until it reads against that surface - so a dark theme gets a light identity on a dark body rather than a dark one on a dark one.UpdateElementStyle's$bgColor,$borderColorand$fontColorare still emitted inline on the node and continue to take precedence.8 files, +324/-42, one commit. Three of those files are tests and one is the changeset; the production change is 3 files, +59/-42.
The open question this PR used to carry is now answered
Earlier revisions hard-coded the fill to
#ffffffand asked whether the colours should come from theme variables instead, deferring to #7868. Review said not to wait, which was right - but following it up showed that moving only the fill would have shipped a bug: the oldensureReadableclamped the identity colour darker, which is correct on a white fill and wrong the moment the fill follows the theme, becausetheme-dark's surface is dark. Darkening the identity colour into a dark background is the same unreadability the redesign is meant to remove, pointing the other way.It also could not be fixed where it was:
elementCssStylesonly received the c4 config, so it had no way to know what surface it was drawing on.So the palette-derived colours are emitted by the stylesheet, which is the one place with both
getConfig().c4and the theme variables, using the same CSSOM construction as the existing per-type font rules.readableOn()picks the shift direction by measuring contrast against the surface rather than assuming one, so light themes darken and dark themes lighten. Dark themes are supported here rather than deferred, and there is no hard-coded white left.The fill uses
options.background.mainBkg- the flowchart/state/er convention for a node fill - is#ECECFFin the default theme and#cde498in forest, which would make an "outline" element lavender or olive;backgroundis the only public theme variable that is near-white in every light theme and genuinely dark intheme-dark. Happy to switch if you would rather C4 match the flowchart convention exactly.Two behaviour changes worth calling out
<type>_border_colorno longer affects rendering. The border is the identity colour derived from<type>_bg_color. The 40<type>_border_colorconfig keys still exist and still validate, but setting one has no effect. There is no way to detect "the user customised this" at runtime, since config always carries a default, so this is documented in the changeset rather than handled in code. Whether those keys should be deprecated in the schema, or honoured as an explicit stroke override that wins over the derived colour, is a maintainer call - happy to add the override if you want the escape hatch.Tests
c4Colors.spec.tsonreadableOn: passthrough when a colour already reads, darkening on a light surface, lightening on a dark one, every palette colour reaching 4.5:1 on#ffffff/#f4f4f4/#333333, an unparseable value returned untouched, and the invariant that the result is never less readable than the input.styles.spec.tson the generated stylesheet: the body takes the surface colour, two palette entries produce two different identity colours, the identity colour is lighter on a dark surface than on a light one, and it is set on the group so the label inherits it.C4.9, adefaultvsdarkimgSnapshotTest. Worth noting no C4 Cypress spec set a theme before this, so Argos could not have shown a dark-theme problem at all.argoswill show the intended legacy-colours -> outline change plus the new dark-theme case.Part of the C4 modernization tracked in #7849; the shape migration it builds on (#7842) has merged.
Summary
c4model.comoutline style.readableOnutilities for WCAG AA contrast.mermaidchangeset.stereotypelabel routing from PR#7842.#7868and tracker#7849.Validation