fix(radar): align axis labels based on angular position to prevent clipping

[Dharya-dev]

Summary

Fixes #7683

Radar chart axis labels are currently rendered without explicit text-anchor or dominant-baseline SVG attributes. Because SVG text defaults to text-anchor: start, labels positioned on the left side of the radar chart extend leftward - often past the viewBox boundary - making them partially clipped or completely hidden.

This is especially noticeable with longer labels like Intelligence, which can not fit within the available margin on that side.

Changes

In renderer.ts drawAxes(), I now set the text-anchor and dominant-baseline attributes dynamically based on each label angular position around the chart:

• Right side (cos > 0): text-anchor=start
• Left side (cos < 0): text-anchor=end
• Top/bottom (cos approx 0): text-anchor=middle
• Above center (sin < 0): dominant-baseline=auto
• Below center (sin > 0): dominant-baseline=hanging
• Horizontal (sin approx 0): dominant-baseline=central

This ensures labels always grow away from the chart center, keeping them within the viewBox without needing to increase margins.

Also refactored to extract Math.cos/Math.sin into local variables to avoid repeated trig calls for the same angle.

Before / After

Before: Labels on the left side of the chart overflow past the viewBox, getting clipped. The Intelligence label from the issue is partially cut off.

After: Labels on the left use text-anchor: end so they grow rightward toward the chart center. Labels at the top/bottom use middle so they are centered on their axis line. All labels remain fully readable regardless of length.

[changeset-bot]

🦋 Changeset detected

Latest commit: 841d70b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
mermaid	Patch

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

[netlify]

✅ Deploy Preview for mermaid-js ready!

Name	Link
🔨 Latest commit	841d70b
🔍 Latest deploy log	https://app.netlify.com/projects/mermaid-js/deploys/6a1e8f03267bed00081636a6
😎 Deploy Preview	https://deploy-preview-7781--mermaid-js.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[pkg-pr-new]

Open in StackBlitz

@mermaid-js/examples

npm i https://pkg.pr.new/@mermaid-js/examples@7781

mermaid

npm i https://pkg.pr.new/mermaid@7781

@mermaid-js/layout-elk

npm i https://pkg.pr.new/@mermaid-js/layout-elk@7781

@mermaid-js/layout-tidy-tree

npm i https://pkg.pr.new/@mermaid-js/layout-tidy-tree@7781

@mermaid-js/mermaid-zenuml

npm i https://pkg.pr.new/@mermaid-js/mermaid-zenuml@7781

@mermaid-js/parser

npm i https://pkg.pr.new/@mermaid-js/parser@7781

@mermaid-js/tiny

npm i https://pkg.pr.new/@mermaid-js/tiny@7781

commit: 841d70b

[codecov]

Codecov Report

❌ Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 3.26%. Comparing base (666e872) to head (841d70b).
⚠️ Report is 2 commits behind head on develop.

Files with missing lines	Patch %	Lines
packages/mermaid/src/diagrams/radar/renderer.ts	0.00%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           develop   #7781      +/-   ##
==========================================
- Coverage     3.27%   3.26%   -0.01%     
==========================================
  Files          599     599              
  Lines        61064   61071       +7     
  Branches       921     921              
==========================================
  Hits          1997    1997              
- Misses       59067   59074       +7     

Flag	Coverage Δ
unit	3.26% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/mermaid/src/diagrams/radar/styles.ts	2.04% <ø> (ø)
packages/mermaid/src/diagrams/radar/renderer.ts	0.55% <0.00%> (-0.03%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[argos-ci]

The latest updates on your projects. Learn more about Argos notifications ↗︎

Build	Status	Details	Updated (UTC)
default (Inspect)	👍 Changes approved	6 changed	Jun 2, 2026, 8:11 AM

[pbrolin47]

Hi @Dharya-dev,
I tested locally with the changes in the PR, but the demo page for radar diagrams still have problem with partly hidden label.

[Dharya-dev]

Thanks for testing and the screenshot @pbrolin47! You're right — the text-anchor fix alone wasn't enough. The label text (e.g. Intelligence) extends beyond the SVG viewport boundary, so even though it's correctly anchored away from the center, it gets clipped by the SVG edge.

I've pushed an update with two changes:

1. overflow: visible on the SVG element — allows axis labels to render beyond the viewBox boundary instead of being clipped. This is the same approach used by the venn diagram renderer.

2. Small pixel offset (labelPad) — nudges each label a few pixels further outward along its axis direction, giving extra breathing room between the label text and the chart boundary.

Both changes are rebased on latest develop. Could you give it another test when you get a chance?

[Dharya-dev]

Quick follow-up — I found a CSS specificity issue that was silently defeating the text-anchor fix.

The .radarAxisLabel CSS class in styles.ts hard-codes:
\\css
dominant-baseline: middle;
text-anchor: middle;
\\

In SVG, CSS rules override presentation attributes set via .attr(). So my angle-aware text-anchor/dominant-baseline values were being silently overridden back to middle by the class — explaining why labels were still clipping despite my earlier fix.

I've removed those two hard-coded lines from the CSS class since the renderer now sets them dynamically per-label based on angular position. The latest push includes this fix.

[Dharya-dev]

Update — fix verified locally ✅

@pbrolin47 Thanks again for catching this! I found the actual root cause and pushed a proper fix.

Root cause: CSS specificity override

The .radarAxisLabel CSS class in styles.ts was hard-coding:
\\css
dominant-baseline: middle;
text-anchor: middle;
\
In SVG, CSS rules override presentation attributes set via .attr(). So my angle-aware text-anchor/dominant-baseline values (start/end/middle based on angle) were being silently overridden back to middle by the CSS class — causing labels to remain centered on the axis endpoint and extend past the SVG boundary.

Fix (this push):

1. Removed text-anchor: middle and dominant-baseline: middle from the .radarAxisLabel CSS class — the renderer now owns these properties and sets them dynamically per-label based on angular position.
2. Added overflow: visible on the SVG element — safety net so labels that barely extend past the edge still render (same pattern as vennRenderer).
3. Added a small labelPad pixel offset to nudge labels slightly outward for visual breathing room.

Tested locally — all 5 labels (Agility, Speed, Strength, Stamina, Intelligence) are now fully visible on all themes (default, forest, dark, custom). Screenshot of fixed Forest + Dark theme below:

[ashishjain0512]

Hey @Dharya-dev

Thanks you for the updates, Glad to see this is moving in the right direction, could you add a changeset file to the PR, so that we can start the review.

[Dharya-dev]

Hey @ashishjain0512, thanks for the reminder! Just pushed the changeset — .changeset/fix-radar-axis-label-clipping.md is now included in the PR. Let me know if anything else needs adjusting!

[ashishjain0512]

[sisyphus-bot]

Nice fix. The diagnosis in the changeset is what makes this PR — calling out that the CSS rule on .radarAxisLabel was silently overriding any SVG presentation attribute is exactly the kind of subtle gotcha that easily eats hours, and explaining why the per-element attrs are necessary saves the next person from re-discovering it.

The math holds up too: with the default config (width=600, marginLeft=50, axisLabelFactor=1.05), a left-side label sits at SVG x≈35 — only 35px of clearance to the viewBox edge — so anything longer than ~70px (e.g. "Intelligence") was always going to bleed out under the previous text-anchor: middle. The fix combo of (a) anchoring outward by quadrant and (b) overflow: visible on the SVG lets the label render fully without overlapping the chart polygon. 👌

What's working well

• 🎉 [praise] .changeset/fix-radar-axis-label-clipping.md — the explanation of "CSS rules override SVG presentation attributes and were silently defeating the per-label alignment fix" is the most valuable part of this PR. Future contributors will thank you.
• 🎉 [praise] renderer.ts:106-107 — extracting cosA / sinA once and reusing them through the loop is a small but clean refactor; nice while you're already in the area.

Things to consider (non-blocking)

• 🟢 [nit] renderer.ts:119 — labelPad = 4 is a reasonable magic number, but since the rest of the diagram already accepts an axisLabelFactor config, a future enhancement could make this relative to axisLabelFontSize (e.g. axisLabelFontSize * 0.25) so the padding scales when users bump the font. Pure follow-up, not for this PR.
• 🟢 [nit] renderer.ts:115 — the 0.01 threshold for "near zero" is fine in practice (the only exact zeros come from cos(±π/2) and sin(0), which are FP-exact for typical axis counts), but a one-line const EPSILON = 0.01; at the top of drawAxes would document intent.
• 💡 [suggestion] cypress/integration/rendering/radar/radar.spec.js — the existing "should render a complex radar diagram" test already uses "Intelligence" and will catch this visually via Argos, so coverage isn't a blocker. But a focused new test that puts a long label on each cardinal side (top, right, bottom, left) of a 4-axis chart would make any future regression in the anchor logic immediately diagnostic from the snapshot diff alone, rather than tangled up with theme/legend/curve changes. Worth a look if it's quick.

Security

The change is structural (text-anchor, dominant-baseline, overflow attribute values come from hardcoded ternaries; the label still flows through D3's text-encoding .text() API). No new user-controlled input reaches a DOM sink, and DOMPurify still wraps the final SVG output. No XSS concerns.

One out-of-scope observation

renderer.ts:41-45 — the radarTitle text element doesn't set text-anchor on the element either, but the CSS .radarTitle { text-anchor: middle; ... } in styles.ts:46-51 is doing the right thing for it (since the title sits centered above the chart, middle is correct and there's no overlap problem). Not asking you to change it — just flagging that the asymmetry (axis labels lost their CSS overrides; title kept them) is intentional and worth a comment in the changeset if a future reviewer wonders why.

Heads up that this changes the rendered output of radar.spec.js test #25 ("should render a complex radar diagram"), so Argos will need a maintainer to accept the new snapshot. Normal for this kind of fix.

Approving — let's get this in. Thanks for the careful write-up.