In Another Stab at the Perfect CSS Pie Chart… Sans JavaScript! (2026-06-04), CSS-Tricks revisited the technique of rendering pie charts without JavaScript using conic-gradient. Simply passing proportions into color stops in conic-gradient draws pie slices, and feeding values via CSS variables (custom properties) enables creating lightweight, print-friendly charts while keeping markup decoupled from numerical values. This exact mindset extends beyond pie charts to bar charts using linear-gradient and progress rings using conic-gradient masks.
In client web development, teams have repeatedly experienced incidents where "heavy JS libraries like Chart.js, D3.js, or ApexCharts are imported in full merely to display track-record numbers on a corporate site or simple KPIs in an admin dashboard, bloating bundles and piling up maintenance costs across version upgrades and bug fixes." Supporting client web development, we view this not as a question of "whether all charts should be built with CSS," but as a design challenge of "distinguishing cases where CSS suffices from those where JS libraries are appropriate, cutting dependencies, and delivering solutions that are accessible, printable, and SEO-resilient." Connecting with our policy of reducing JS dependencies discussed in Ditching JS Libraries with CSS Anchor Positioning (GH Media) and our evaluation criteria for new features covered in Using Modern Native CSS Features in Client Work (GH Media), this article presents "Lightweight Data Visualization (JS-Free Charts) Implementation Support" as a structured client service package.
Why rebuild charts in CSS now
| Dimension | JS chart libraries (traditional) | CSS implementation (2026) |
|---|---|---|
| Dependency | Add Chart.js / D3 / ApexCharts | No additional libraries required |
| Bundle size | Increases by tens to hundreds of kilobytes | Near zero |
| Maintenance | Requires continuous version tracking | Resistant to obsolescence as a browser standard |
| Accessibility | Canvas often cannot be read by screen readers | Numerical text can be preserved |
| Print and SEO | Canvas breaks when printed and is not indexed | Numbers remain in the DOM and are indexed |
| Update frequency | Strong for real-time updates | Suited for static, low-frequency updates |
In other words, "rendering charts with JS libraries" and "delivering maintainable visualizations with minimal dependencies" are two entirely different things. In client work as well, "shifting simple visualizations to CSS, keeping complex ones in JS, and designing that boundary before delivery" has become a quality baseline. This allows us to guarantee an architecture with reduced JS dependencies as a deliverable.
What CSS charts can do / what they are not suited for
1. Rendering pie and doughnut charts with conic-gradient
conic-gradient is a gradient that sweeps colors angularly around a center point. By specifying percentages at color stops, you can draw pie wedges—a pie chart—without JavaScript. Punching out the center using a radial-gradient mask or mask turns it into a doughnut chart (progress ring).
.pie {
--a: 45%; /* セグメントA */
--b: 75%; /* セグメントA+B */
aspect-ratio: 1;
border-radius: 50%;
background: conic-gradient(
#2f6df6 0 var(--a),
#f6a72f var(--a) var(--b),
#e1e5ea var(--b) 100%
);
}2. Injecting values via CSS variables
Passing proportions via CSS variables like --a allows you to separate markup (numerical values) from presentation (CSS). Passing them as inline variables like style="--a: 45%" allows values calculated on the template side to be reflected directly while reusing the chart's underlying CSS. Registering them with types via @property also stabilizes value interpolation (animations).
3. Progress rings and bar charts
A progress ring is an application of the doughnut chart, representing completion rates with a single variable. For bar charts, simply specifying percentages for linear-gradient or width / inline-size makes the element itself reflect the length of the value. In both cases, the decisive advantage over Canvas is the ability to co-locate readable numerical text directly in the DOM.
Cases where CSS is not suited
CSS falls apart for line charts, scatter plots, dynamic rendering of large datasets, rich interactions such as tooltips and zooming, and real-time updates. Chart.js or D3.js remain appropriate in these scenarios. CSS charts should be confined to areas that are "simple, static, updated infrequently, and focused on print/SEO."
5 phases of our client offering: "Lightweight Data Visualization (JS-Free Charts) Implementation Support"
Phase 1: Inventory and assessment (1 week)
- Cataloging existing site / dashboard charts and numerical representations
- Measuring in-use JS libraries and dependency footprints
- Reviewing update frequencies and interaction requirements for each chart
- Deliverable: Chart inventory spreadsheet + JS removal feasibility report
Phase 2: Design (1 week)
- Separating visualizations to move to CSS from those to retain in JS
- Establishing accessibility policies (numerical text / ARIA)
- Establishing print, color vision diversity, and color palette policies
- Deliverable: Implementation blueprint + visualization design document
Phase 3: Implementation (1–3 weeks)
- Implementing charts via conic-gradient, linear-gradient, and CSS variables
- Adding co-located numerical text, aria attributes, and print styles
- Implementing fallbacks for unsupported browsers
- Deliverables: Implemented components + implementation standard documentation
Phase 4: Verification and handover (1 week)
- Verifying across major browsers, print output, and screen readers
- Checking legibility through color vision diversity simulations
- Deliverables: Verification report + maintenance procedure manual
Phase 5: Continuous maintenance (ongoing)
- Periodic tracking of browser support status
- Evaluating phased removal of fallbacks
- Implementing new charts and evaluating future JS conversion needs
Implementation standards set for custom development
| Application | Recommendation | Avoid |
|---|---|---|
| Pie charts / doughnuts | conic-gradient + CSS variables | Using Chart.js for a simple circle |
| Bar charts | linear-gradient / inline-size | Static bar charts in Canvas |
| Progress rings | conic-gradient + mask | Loading a library for a single completion rate |
| Value handover | Inline CSS variables / @property | Writing directly to the DOM with JS |
| Value preservation | Co-locating text in the DOM | Numbers lost inside Canvas alone |
| Complex and dynamic | Adopting JS libraries | Forcing reproduction in CSS |
Which projects need this and which do not
| Projects requiring this | Low-priority projects |
|---|---|
| Corporate sites displaying performance metrics | Sites with virtually no data visualization |
| Admin panels displaying simple KPIs | Core advanced analytics tools |
| Long-term operations seeking to trim bundle size | Short-lived campaign landing pages |
| Print / PDF reporting requirements | Completed strictly within screen display |
| Accessibility and SEO are requirements | Virtually no constraints |
Six clauses to include in custom development contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target scope | Types of charts to convert to CSS | Boundaries for pie, bar, and ring charts |
| Scope retained in JS | Visualizations keeping libraries | Criteria for dynamic requirements |
| Browser compatibility | Guaranteed scope | Extent of fallbacks |
| Accessibility | Numerical text and ARIA standards | Verification scope |
| Print and SEO | Print styles / DOM values | Reporting requirements |
| Ongoing maintenance | Monitoring browser support status | Operating costs |
Client ROI estimate (assumed for KPI dashboards)
| Item | JS library implementation | CSS-centric implementation | Difference |
|---|---|---|---|
| Dependency libraries | Managing multiple dependencies | Reduction / removal | Smaller dependency tree |
| Bundle size | Increases by tens to hundreds of KB | Near zero | Faster rendering speed |
| Bug remediation | Occurs with version tracking | Reduced through browser standards | Lower maintenance workload |
| Accessibility | Unreadable by screen readers in Canvas | Numerical text preserved | Avoidance of refactoring costs |
| Annual benefit | — | — | Dependency reduction + compressed maintenance workload |
Even with just an initial diagnostic (starting from 200,000 JPY), making visible how much JS dependency can be removed from your current charts is valuable in itself. Maintenance overhead from libraries adopted for a single simple pie chart typically compounds gradually over several years. For rendering performance considerations, please also read our Core Web Vitals Improvement Guide (GH Media).
Five common pitfalls to avoid
Pitfall 1: Omitting numerical text
Rendering only conic-gradient leaves screen readers with nothing to announce. Always co-locate aria-label or visually hidden numerical text.
Pitfall 2: Colors disappearing in print
Background colors are frequently omitted during printing. Design with borders, patterns, and numerical labels so charts remain readable without color.
Pitfall 3: Neglecting browser compatibility and fallbacks
Discrepancies in conic-gradient or @property behavior cause rendering breaks. Provide feature detection and fallback presentations to numerical text or simple bars.
Pitfall 4: Forcing CSS on frequently updated data
Attempting to replicate real-time updates or complex interactions in CSS leads to failure. Cleanly delegate dynamic requirements to JS libraries.
Pitfall 5: Ignoring color vision diversity
Distinguishing segments using only similar hues makes them indistinguishable for many users. Combine lightness contrast, patterns, and text labels. Use our Web Accessibility Implementation Guide (GH Media) as the overall accessibility benchmark.
90-day action plan
| Week | Action |
|---|---|
| Week 1 | Cataloging charts and numerical displays + auditing dependencies |
| Week 2 | Assessing feasibility of JS removal + defining accessibility/print policies |
| Week 3〜5 | CSS implementation of pie, bar, and ring charts + co-locating numerical text |
| Week 6 | Verifying across major browsers, print output, and screen readers |
| Week 7〜13 | Monitoring compatibility + evaluating CSS vs. JS for new charts |
Conclusion: From drawing with libraries to delivering with reduced dependencies
Being able to draw pie charts with conic-gradient without JavaScript accelerates a shift in visualization strategy from "drawing everything with libraries" to "shifting simple charts to CSS and keeping only complex ones in JS." In client web development, our "Lightweight Data Visualization (JS-Free Charts) Implementation Support"—which distinguishes cases where CSS is sufficient from those where JS is warranted, delivering solutions that are accessible, printable, and SEO-resilient—serves as our core service to deliver deliverables with reduced dependencies and maintenance overhead. If you are also reconsidering your dashboard metrics architecture, please consult our GA4 Beginner's Guide (GH Media).
If you are looking to "remove libraries added for simple charts," "lighten KPI dashboards," or "rebuild visualizations to withstand printing and screen readers," please feel free to reach out via our contact form.
Sources
- Another Stab at the Perfect CSS Pie Chart… Sans JavaScript!（CSS-Tricks 2026-06-04）
- Ditching JS Libraries with CSS Anchor Positioning (GH Media)
- Using Modern Native CSS Features in Client Development (GH Media)
- Core Web Vitals Improvement Guide (GH Media)
- Web Accessibility Implementation Guide (GH Media)
- GA4 beginner guide (GH Media)
