Charts.css(chartscss.org)
chartscss.org
Charts.css
https://chartscss.org/
25 comments
None of these charts seem to show labels on both axes.
Blocked on conversion from flex to grid, which never happened: https://github.com/ChartsCSS/charts.css/issues/45
Is the project no longer in development?
The last one here seems to show both. Maybe its just a config issue
https://chartscss.org/components/axes/
https://chartscss.org/components/axes/
Wow, that is extremely weird. I feel like we must be missing something, I just can't imagine this is possibly actually the case
Or data labels on the bars themselves
That appears to be supported:
https://chartscss.org/components/labels/
https://chartscss.org/components/labels/
the tailwind-esque ergonomics are appealing, especially considering how painful the current meta (chart.js spaghetti) can be to maintain.
from github it looks unmaintained :(
Why not just use a canvas or a SVG ?
Chartist.js is all SVG based and < 10kb in size (no external dependencies)
https://gionkunz.github.io/chartist-js/index.html
https://gionkunz.github.io/chartist-js/index.html
It requires a lot more work to make it accessible for screen readers. This just falls back to a table element.
How would you do that client side in pure CSS? "No JS" seems to be a goal of the project.
SVG doesn’t require JS.
Yes, I understand that. But it does require some method of creating the SVG data, which is generally going to be more difficult than styling td elements with `--start: 0.2; --end: 0.4;`. Most extant libraries for this use JS.
SVG complexity is a good counterpoint to “why this instead of SVG”. But I don’t think we need to even address the claim that most tools for SVG generation use JS, if the concern is JS on the client.
Realistically, on a scale beyond very few graphs, it’s pretty likely some sort of software is going to be used to process data into markup. At which point, if the desired result is static markup, it doesn’t really matter (to the end user) whether that software is written in JS or some other language. That’s a toolchain concern. It probably doesn’t matter much if at all (to the end user) whether the resulting markup is HTML or SVG. There may be some imperceptible performance difference, or slightly different accessibility requirements. But neither requires users to run JS.
If I were evaluating this choice, it would almost certainly come down to what’s most familiar, or what most readily integrates with other parts of the project’s stack and/or data sources. And I could easily imagine even that evaluation being a wash.
Realistically, on a scale beyond very few graphs, it’s pretty likely some sort of software is going to be used to process data into markup. At which point, if the desired result is static markup, it doesn’t really matter (to the end user) whether that software is written in JS or some other language. That’s a toolchain concern. It probably doesn’t matter much if at all (to the end user) whether the resulting markup is HTML or SVG. There may be some imperceptible performance difference, or slightly different accessibility requirements. But neither requires users to run JS.
If I were evaluating this choice, it would almost certainly come down to what’s most familiar, or what most readily integrates with other parts of the project’s stack and/or data sources. And I could easily imagine even that evaluation being a wash.
> SVG complexity is a good counterpoint to “why this instead of SVG”. But I don’t think we need to even address the claim that most tools for SVG generation use JS, if the concern is JS on the client.
If you want to address the generation of charts on the client, then, yes, JS is something that needs to be addressed, because SVG (or Canvas) are not in and of themselves systems for generating charts. There isn't a <PieChart> primitive within the SVG spec, to my knowledge.
The entire purpose of this library seems to be generating charts in pure markup without any scripting language dependencies. Trying to pretend that isn't relevant, or suggesting that "SVG" is, in and of itself, a viable substitute is just really weird.
If you want to address the generation of charts on the client, then, yes, JS is something that needs to be addressed, because SVG (or Canvas) are not in and of themselves systems for generating charts. There isn't a <PieChart> primitive within the SVG spec, to my knowledge.
The entire purpose of this library seems to be generating charts in pure markup without any scripting language dependencies. Trying to pretend that isn't relevant, or suggesting that "SVG" is, in and of itself, a viable substitute is just really weird.
I’ve had no problem rendering far more complex graphics than a pie chart, with SVG, without sending a single byte of JS to clients (not just the SVGs, a variety of fairly interactive content!). I realize that’s fairly niche, and it’s a bit of a personal special interest. But I can say with certainty that it’s possible, because I have done it.
Sure, I have used JS (TS) for building these projects, but that’s immaterial because it never ships to clients.
As for pie chart “primitives”, I’m not asking you to take my word for it but I also can say with relatively high confidence that SVG as a technology is capable of the kinds of composition needed for that. It probably won’t match the ergonomics of a few CSS variables, but it could come close if you’re willing to overlook the verbosity of XML syntax.
Not that I’m saying you or anyone should do that! My original response wasn’t intended to persuade you or anyone that SVG is a better choice of technology for this purpose. Only to clarify that there is no inherent requirement to run client side JS to render SVG charts. That’s probably not super interesting in its own right, it’s only a clarifying statement of fact.
Sure, I have used JS (TS) for building these projects, but that’s immaterial because it never ships to clients.
As for pie chart “primitives”, I’m not asking you to take my word for it but I also can say with relatively high confidence that SVG as a technology is capable of the kinds of composition needed for that. It probably won’t match the ergonomics of a few CSS variables, but it could come close if you’re willing to overlook the verbosity of XML syntax.
Not that I’m saying you or anyone should do that! My original response wasn’t intended to persuade you or anyone that SVG is a better choice of technology for this purpose. Only to clarify that there is no inherent requirement to run client side JS to render SVG charts. That’s probably not super interesting in its own right, it’s only a clarifying statement of fact.
In fact, the SVG specification is included in the HTML5 specification.
Depends on the amount of data really.
[deleted]
I'd suggest pluck out some of the features you find after navigating through to https://chartscss.org/components/ and displaying them on this page so users without a lot of time or patience can quickly look through, maybe copy-paste the code examples to play with it a bit, and get a quick idea of how suitable it is for them.