3 ms·
Charts.css
- noman-land 2y agoNone of these charts seem to show labels on both axes.
- bowsamic 2y agoWow, that is extremely weird. I feel like we must be missing something, I just can't imagine this is possibly actually the case
- buovjaga 2y agoBlocked on conversion from flex to grid, which never happened: https://github.com/ChartsCSS/charts.css/issues/45 https://github.com/ChartsCSS/charts.css/issues/45
- stogot 2y agoIs the project no longer in development?
- whall6 2y agoOr data labels on the bars themselves
- thom 2y agoThat appears to be supported: https://chartscss.org/components/labels/ https://chartscss.org/components/labels/
- santa_boy 2y agoThe last one here seems to show both. Maybe its just a config issue https://chartscss.org/components/axes/ https://chartscss.org/components/axes/
- claytonaalves 2y agoWhy not just use a canvas or a SVG ?
- marcusb 2y agoHow would you do that client side in pure CSS? "No JS" seems to be a goal of the project.
- eyelidlessness 2y agoSVG doesn’t require JS.
- cluckindan 2y agoIn fact, the SVG specification is included in the HTML5 specification.
- marcusb 2y agoYes, 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.
- eyelidlessness 2y agoSVG 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.
- Liquix 2y agothe tailwind-esque ergonomics are appealing, especially considering how painful the current meta (chart.js spaghetti) can be to maintain.
- fdasbbhu 2y ago[dead]
- caramellow 2y agoI was a bit confused to not see that first page simply demonstrate a few examples of charts and that I had to click through each type to get an idea of this library. I'd suggest pluck out some of the features you find after navigating through to https://chartscss.org/components/ 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.
- deleted 2y ago[deleted]
- keevitaja 2y agofrom github it looks unmaintained :(