Charts.css
chartscss.org
chartscss.org
(
echo "<table class='charts-css bar show-labels show-heading'>"
echo "<caption>Size of Charts.css releases</caption>"
for version in $(curl -sS https://github.com/ChartsCSS/charts.css/releases | grep -o releases/tag/[0-9.]* | cut -d/ -f3 | tac); do
url=https://cdn.jsdelivr.net/npm/charts.css@$version/dist/charts.min.css
size=$(($(curl -sS "$url" | wc -c)/1024))
echo "<tr><th>v$version</th><td style='--size: calc($size/100)'>${size}KiB</td></tr>"
done
echo "</table><link rel=stylesheet href='$url'>"
) > size-chart.html
Since I couldn't easily find how large it was and wanted to try it out at the same time.
I actually thought it was number of downloads until I rechecked your script.
Obligatory: https://xkcd.com/833/
As an aside, a friend of mine has already arranged (as a joke) the rights to compile and remix any bash snippets I post in chat groups in a blog or book. Maybe I should write more about this, but then, it's probably most helpful exactly because I just drop it in places rather than writing a comprehensive work that nobody sits down to read. Still, I'm curious what the syntax/feature/pattern is that you found useful :)
You should definitely try mdbook if you want to keep it in a book format as it offers good fulltext search
And I found the entire script interesting I would definitely try this once I get to my laptop as I’m currently surfing HN on my phone
`pv` (pipe view) is rather simple but I use it for viewing a lot and sometimes rate-limiting transfers. Usage is simple: `curl huge-file | pv | some-operation` will show you the progress (okay, curl already does... but pv works for any pipe input, and pv can work in line mode with -l so you can see how many lines (records, presumably) it processed).
`progress` is even simpler! Just type progress in a random terminal while, in another, you are running an operation like cp, gzip, etc.
$ progress
[10123] bzip2 /tmp/test
32.5% (127.0 MiB / 390.6 MiB)
I also love progress just because it's such a hack. It hooks into the process and monitors file operations. Simple but effective. Somehow it works super well because it manages to ignore everything irrelevant and only shows you the file handle you care about (you can give it hints if necessary, I've used that maybe once in ten years).
`jq` takes JSON data and either pretty-prints (default) or operates on it:
$ echo '{"whoami": "root"}' | jq
{
"whoami": "root"
}
# imagine colored output above
$ echo '{"whoami": "root"}' | jq .whoami
"root"
$ echo '{"users": [{"name": "abc", ...}, ...]}' | jq '.users[].name'
# prints the name of all users in this array
$ curl localhost/api/v1/users | jq '.users[] | "\(.name) \(.age)"' | sort -n -k 2 | tail -1 && echo "is our oldest user!"I’m definitely going to take a note of this and add to my TIL Notes so I can always refer back to this
I just wanted to thank you for teaching me something totally new today
Also, jq is amazing and is basically sed for json data.
Also xidel is a tool everyone should know.
Just out of curiosity are you into DevOps
$ seq 1 10 | pyp "sum(map(int, lines))" or along with `jq` and `pup` (html parser)
$ curl https://public-api.wordpress.com/rest/v1.1/sites/username.wordpress.com/posts | jq -r ".posts.content" | pyp "html.unescape(x)" | pup a attr{href}syntax. Like, I knew about file redirection, but I didn't know you could group commands like that and redirect all their output with one operator. I would have had to do a bunch of appending with `>>`
And even more. Really great that you van manipulate the elements as css. Most chart libs I’ve dealt with makes non-trivial customization impossible.
I’ll probably be building this in as Lowdefy blocks[1].
Just curious, did you consider just branding it as sparks.css / sprites.css or something? Going the spark / sprite route just sets the expectations a lot lower imo. Although congrats, you are really close to fully functional charts here! Really interested to see how far this can go.
[1] - https://lowdefy.com
Limitations, definitely needs a lot more connections for other DBs etc. Also we need first class support for auth and athorization, currently bring your own openid connect provider.
I’m definitely going to try this for one of my projects
Loading failed for the <script> with source “https://d33wubrfki0l68.cloudfront.net/js/3d627f4dd8e7eb6e7cc....
Lowdefy loading icon just dutifully hops up and down, left and right.
This version (OP's) is way more polished and almost certainly more widely useful. But mine had the features of (a) being generated from markdown and (b) defaulting to a list presentation of the data under different styles so the data remained accessible.
Having more charting options that don't require javascript to do simple things is a good thing.
[0] https://rbitr.github.io/ChartS.css/ [1] https://news.ycombinator.com/item?id=23270581
I really wish this super small library named Chartist was more actively developed. It's only 10kb in size and generates SVG charts.
The huge benefit of SVG is that it's natively responsive and also prints extremely well. Wheres CSS doesn't
Edit: I also maintain my resume as responsive HTML. I haven’t taken the time to address print at all, but having previewed my own print rendering it definitely needs a lot of work before it’s print/PDF ready.
Dynamically growing/shrinking a piechart in CSS is much more difficult to implement. Where as with SVG, it just works as-is and no additional effort needs to be done to make it work.
By your definition any bitmap is “responsive”
SVG can’t really be responsive since values are generally declared as attributes. Good luck changing a path via media query.
The most responsive SVGs really only hide/show detail depending on size, but they don’t reshuffle unless you literally have both layouts in the SVG.
Regarding changing layout in SVG, you just need the `use` tag.
Responsive does include other methods as well, but nobody looks at a CSS-less page and calls that responsive because the text always fits the window. That’s just too broad of a definition.
The comment I was replying to specifically mentioned that “SVGs are responsive because they resize without additional effort.” That’s blatantly false. “No additional effort” only gives you an SVG that scales (just like images can, and you don’t call images responsive)
On review, however, SVGs can be made responsive, it’s just that it’s not easier than regular HTML.
> Responsive does include other methods as well, but nobody looks at a CSS-less page and calls that responsive because the text always fits the window. That’s just too broad of a definition.
Why? You’re the one making the claim here. The original coining of the term and the author’s 10 year piece certainly talk about other techniques. But not as some formal definition, rather as ways to achieve the original goal: one design which serves all. If the design has the default layout, why would it need to do more?
> The comment I was replying to specifically mentioned that “SVGs are responsive because they resize without additional effort.” That’s blatantly false. “No additional effort” only gives you an SVG that scales (just like images can, and you don’t call images responsive)
Now this is beyond the pale. Just search “responsive images” and filter for before the picture tag and srcset attribute and you’ll see that this is exactly what was expected. Of course you can do more now, but I don’t think it’s even common practice except when automated by tooling.
But more than that, depending on usage, there are ways SVG can scale that raster images can’t. Position and size can scale independently. Images which benefit from it can change aspect ratio without a problem (you can see an example of this on my personal site, link in profile, scaling from very wide to very narrow).
1. vector-effect[1] allows you to specify, per element, how different aspects of its rendering scale—or don’t—proportional to the containing viewBox.
2. You can nest viewBox coordinates (symbol element or nested SVG) to override the relative proportions of child elements without actually changing the space they take up on their container.
3. You can actually scale real (accessible) text, as if it’s a graphic, to fit a container (textLength attribute) without weird hacks or JS.
1: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/v...
<link rel="stylesheet" media="print" href="print.css">EDIT: It looks like they have hover interaction, but it's not shown on the homepage.
Documentation is hard.
It is! But (if you’ll pardon my aside) increasingly my career/nerd goal is to promote documentation as an implementation source of truth. Documentation is hard because it’s seen as an additional task. But it’s possible to design interfaces where documentation is the API, or at least a first class part of it which determines API boundary behavior. It’s hard to do that upfront, but it’s great if you have the right primitives for it.
Having said that, I had to unfortunately abandon it because the ad-hoc control with Matplotlib [3] in Python is just infectious. Visual manipulations are far less easy to do in Vega. Being in JSON is also a restrictive though, because it is less interpretable by unstructured bots, where charts.css probably excels by design.
[1]: https://vega.github.io [2]: https://altair-viz.github.io [3]: https://matplotlib.org
[1] https://cryptomarketdepth.com/#graph
> Being in JSON is also a restrictive though, because it is less interpretable by unstructured bots, where charts.css probably excels by design.
What do you mean by this?
I meant to point out that Charts.css relies on having <table> elements in the HTML. Vega relies purely on JSON. This may or may not be of concern. For instance, if you care about bots crawling the website for semantic information, then perhaps the Charts.css way of operating on top of <table>s is preferred. A minor point though.
That said, it's a bit of a hack. The best kind of hack, the crazy smart kind, but still a hack. And as such, there are some visualization glitches here and there you wouldn't get with Canvas or SVG.
Still, such a cool idea. I love stretching technologies way beyond their original intent.
Introduction to data visualisation:
https://gss.civilservice.gov.uk/policy-store/introduction-to...
It's OK to use column charts where each column represents a category if and only if there's some ordinal nature along the x axis, i.e. if either of these are true:
A) The categories have a natural ordering (e.g. 'age group'), OR
B) The categories are ordered by their value on the y axis (i.e. the most popular 'reason for visiting the UK' is the first column, and the least popular on the right)
In other cases, a horizontal bar chart is preferable, as it does not lead the reader to mistakenly infer some ordinal relationship between the categories.
For learning how to choose a chart type, people should just buy Say it with charts (https://www.amazon.com/Say-Charts-Executives-Visual-Communic...), read it and complete the exercises.
BTW - another thing that bugs me about that chart: the y axis is labelled as 'thousands', but then the tick marks are labelled 2,000 to 16,000. It would better to use 2, 4, 6, ... for the tick marks, and label the axis as 'millions'. Even better would be to use percentages, and just mention N somewhere in the title.
Which of these charts is clearest? (top-left is the version in the linked guide, bottom-right is my preferred option): https://docs.google.com/spreadsheets/d/1JO2RXDQBJffWQ34QIi79...
Are there any sample graphs using more than 5 data points? I'd also want to see how this scales to reasonable blog-post level graphs which will probably be in the 30+ point range (a data point every five minutes covering a 3 hour range, or hourly for a week, both seem like reasonable minimum data sizes to be able to render well).
I love the potential accessibility benefits of using data tables directly styled like this.
Apart from different chart types, examples on how to rig data/image export will make this even more usefull.
I currently work on accessibility guidelines for visualisations at a national bureau of statistics. This came just at the right time for me as I'm exploring options to improve accessibility beyond the capabilities of libraries like highcharts, vega, charts.js etc. Don't hesitate to contact me. I'm very interested in the possibilities in this approach.
What do you find lacking in the accessibility of tables?
I haven't found a good way to highlight the data points in a table in such a way that it is easy to pick up by a screen reader. I would love a summary tag or similar to be part of the table in the same way we now have caption.
Anyway, I find the solution with tables way better than other html based chart solutions I've seen in regards to accessibility. They usually have a bunch of divs, spans and other tags that are really hard to follow.
Using tables seems so obvious now that I see it. I'm surprised I haven't seen it before. Good job!
We never got rid of 100% of it, but we did get really damn close using Blazor. Only ~180 lines of javascript interop is required for our entire solution last time I checked. This isn't trivial stuff either... We hand-rolled large file upload/download w/ progress, get client rect, get/set cookies, etc.
But then when you take into account data that needs to be inserted for higher resolution at higher zoom levels, it becomes a lot of JS, especially if that data needs to be fetched as the user zooms.
Originally developed by Mozilla, its focus is on beautiful and accurate charts, and displaying data in a good way.
The way this library works is the data is embedded in a table, which then gets converted to a chart by CSS - so if the CSS is disabled, the data is just presented as a table of numbers.
I'm not sure if SVG can be written so that it gracefully falls back like that. You could generate SVG from the table using JavaScript, of course, and just hide the table with JavaScript.
2. I want a graph, not a table. SVG is self-contained so WYSIWYG, always.
3. If you want to show both a graph and a table, with Charts.css your markup would contain the same table twice.
Given the weight and quality, I’d advise against this solution. With 70KB you might as well just load JS and get interactive graphs that don’t have rendering artifacts (line graphs look awful on my phone)
2. Can this be made interactive, e.g. on mouse-over show exact numbers? Without interactivity, it is still kinda lame
Make your CSS fit your HTML. Don't make HTML fit your CSS. This framework uses semantic native tables properly.
- - -
I’m on mobile so I can’t dig into the source, but they claim it’s using semantic HTML and the data is accessible. If you disagree with those claims, perhaps sharing your specific objections would make a better case than just vaguely crapping on the project.
The functionality behind this and others are simple and allow the user to fully stylize however they'd like.
0: https://github.com/mothepro/lit-chart 1: https://mothepro.github.io/lit-chart/
I will definitely keep an eye on it!
I really like the idea of applying a simple css style sheet and using my existing @foreach directives to build charts that look this good.
I had to double check the installation instructions 2x, because I was certain there was some javascript piece I had missed.
Library looks small (not sure how many KB) and full features for a basic charts library.
still a wip: //TODO: docs, tests and data.
I regret that I have but one upvote to give
If I missed something, can you point me to the right place in documentation? That's something that would make this useful.
There is nothing the CSS files of the project could do to help with that - as no help is needed :)
Currently when wanting a chart on a webpage I would fetch the data, transform it to the needed javascript array, add that to the HTML, and then initialize the javascript library painting the chart. With a CSS solution I'd just create a HTML-datatable instead, apply the needed classes and have it be rendered directly. It looks easier, faster and more accessible to me.
The example graphs are a bit flat, but that's just default styling. That's likely changeable with CSS, and animations can also be added that way, there are example for that linked in the docs.
Awesome project.
I’d highly doubt there were browsers supporting these CSS hacks but not supporting SVG.
With the HTML + CSS solution, all my program has to produce is a HTML table. Very easy.
With SVG my program has to create not just a data table, but the custom SVG code to paint the chart, down to each bar. I'm actually doing that on pc-kombo, https://www.pc-kombo.com/us/benchmark/games/cpu/compare?ids%... shows it, the image is SVG. But it's created with https://github.com/DannyBen/victor/, so my ruby code has to describe all the details of that image, including manually saying how each bar chart should look and where on the coordinate system the text goes. Even with the awesome victor library that wasn't all that easy.
Alternative is a JS library that produces the SVG code, but then it's exactly as complicated as with regular JS libraries, it just changes the output.
That's a non-starter for my usage unfortunately, as even degraded IE11 support is swing-able, but completely broken means we cannot use it. We're still seeing corporations and government agencies using IE11 on a regular basis.
Wikimedia claims 3.9% of their users are still IE11, we're closer to 10%, but we're also majority desktop rather than mobile users which is also really rare in 2020.