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 :)
Personally, I didn't know about the
(
... commands ...
) > some_file.txt
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 `>>`
Three tools that I think are less widely known compared to how useful they are: jq, progress, and pv.
`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.
Use -m to monitor instead of doing a one-shot. This will also allow it to calculate the remaining time (for anything running at more than a few kilobytes per second).
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!"
Hey I just get enthusiastic about bash and commandline in general as these tools have saved my hours of work compared to using gui
And I love your enthusiasm in the comment and things you just taught me today.
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
Consider adding zsh and Perl to your toolbelt. Many scripting languages are just as powerful as Perl, but I don't know of anything that has equivalent capability for quick work on the CLI. Check out how the `-pi -E` switches work, for an example: https://perldoc.perl.org/perlrun#-i%5Bextension%5D
Also, jq is amazing and is basically sed for json data.
Well done! This looks impressive and really useful. I’ve been looking for a lightweight sprite / spark lib for a while. Clients always, for some reason, are very impressed by little charts in a table row, doing this witha normal size chart lib kills page performance. I was literally including very basic html indicators in a presentation today and client where really impressed! This really solves that issue!
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.
Lowdefy looks great. I'm currently looking for something like Django Admin that isn't necessarily a part of Django (I'm an Elixir dev myself). Have you used Lowdefy extensively? Pros and cons? Limitations? Are you involved with the project itself?
Yes co-founder here. Been building apps with it for 2 years now. Its really powerful for building data intensive UIs.
Have built full scale dashboard solutions for enterprises, buys with a large CRM like 5 companies combined into one system large. Also quite far along building an MRP on it for a small factory.
The flexibility is what really makes it super. Client says the UX is not great for a specific task, no problem. Let’s imagine something better.
Also scales well when bringing on new devs in the team coz its such a structured way of writing UIs.
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.
Hi, yes often we are also really surprised. One could say its like writing a query, we took a lot of inspiration from MongoDBs query language.
To understand how this is all possible, in short, react components just use props, so just a json tree should already get you to some app description. Then, you just need to express logic, recalculate and update.
To find out how we express logic in yaml, how a look at Lowdefy operators -https://docs.lowdefy.com/operators
Looking forward to seeing what you can build! Let us know if you need any help!
Cool!
I'll have to take the opportunity to mention my own charts.css[0]. It got some interest on HN last year [1] and I unfortunately dropped the ball and didn't make any revisions based on the good feedback I got. As people pointed out, I tried to give it a "cute" name using unicode which unfortunately makes it harder to search for.
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.
I'm not sure I understand how SVG is more natively responsive than CSS? I also haven't had problems printing with CSS - I maintain my resume as a styled HTML document - though I haven't done a ton of web printing so there could be problem cases I haven't faced
CSS can certainly be responsive to a degree, if written to be, but there are definitely some features of SVG that go beyond CSS capabilities. This has more to do with the fact that it’s a graphics format—designed for adaptable scaling from the start, with a simple layout model—than anything else. And of course, CSS has some advantages of its own because it has such a huge range of layout options/techniques.
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.
Yep and I fully intend to when I get back to that. I also intend to extract my dark mode styles in the same way so I can add an optional/progressively enhanced setting to override the prefers-color-scheme query for visitors who (like me) have a non-global preference.
You still haven't given a specific example of how SVG can be responsive. Are you just talking about proportional scaling (resizing the shapes as the container's size changes)? Because if so you can accomplish that in CSS by using percentages for size/position
Having a chart as an SVG grow or shrink in size based on the size of the browser windows is radically easier with SVG than CSS.
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.
The coining of “responsive web design” was a reference to architecture which responds to its present occupants. It’s not about changing shape, it’s about making the same content and experience available regardless of environment. Changing shape or layout is a technique to achieve that, not a defining characteristic.
Regarding changing layout in SVG, you just need the `use` tag.
Again, by your definition, every non-fixed-width HTML page could be called responsive. I don’t think so.
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.
> Again, by your definition, every non-fixed-width HTML page could be called responsive. I don’t think so.
> 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).
Okay, I’ll give three examples from recent work on my personal site:
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.
It’s responsive exactly the same as css, but it gives you composability (reuse of template elements) and size-to-fit text (given a container of size X and text Y, render the text at the maximum size that fits), which are both lacking in html+css.
I'm intrigued, I love CSS-only solutions. The examples are lacking plots with both x & y axes labels though which is among the minimum required functionalities for plotting.
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.
Somehow, I don't see the mention of the Vega visualization grammar [1] as a potential charting library. I think it is incredibly well-done, and is generally intuitive in its API. I've mostly used it through the Python bindings called Altair [2]. The good part is that that general grammar carries over to the browser as a full JSON spec that can be used directly in any language that supports JSON and has a Vega binding (which is pretty much all popular languages).
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.
I think I just stopped my train of thought and hit reply.
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.
oh wow, i really should look into vega now.. i too know little about web technologies and benig handed task to create beautiful graphs in very short period of time... :sigh
This is brilliant. It's all done with clip-path and CSS variables.
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.
Related: If you are interested in understanding when to use a particular type of chart and the best practice for labelling charts, the following is an excellent introduction to the topic:
This guide is nicely written, and mostly useful for tips on labelling, but some of the advice on choosing chart types is bad. There are several examples of column charts used for categorical data, e.g. https://gss.civilservice.gov.uk/wp-content/uploads/2020/04/b...
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.
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.
On the Usage page it shows everything but the result of applying the Chart styling which is one of the first things I want to see in a project like this.
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.
Awesome. With a build step to do some data conversion I can see this being a more accessible option than rendering with canvas or SVG. Not that tables are that accessible but still, a better option. I think you could make that into the main selling point for your apporoach as it's an overlooked and difficult area of visualisation.
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.
The amount of data a table often contain presents an accessibility issue in itself. Simple tables with few datapoints is not a big issue though.
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!
I love a good CSS-only solution because of its statelessness; makes things much easier to reason about IMO. Of course in this case you'll probably have to generate your HTML in some procedural way anyway, but it's still a neat option to have, especially if you're statically-rendering your pages (you can avoid using JS entirely)
100% agree. CSS-only solutions are extremely attractive. Avoiding use of JS entirely is one my team's core values at this stage.
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.
Hmm. You would probably want to implement the actual zoom as a `transform: scale() translate()` regardless, and you could parameterize it with CSS properties like `transform: scale(var(--zoom-scale)) translate(var(--zoom-x), var(--zoom-y))`. But when it comes to getting those numbers and hooking them into the CSS vars, I don't see a way to do that without JS. Certainly, though, the JS could be just a couple lines if you did things this way (mousemove listener on the container, a bit of math to get the relative x/y, and then either a slider or a scroll listener to determine the scale, and these three numbers are plugged directly into the CSS).
Yeah, I suppose are definitely ways to do some basic zoom with just CSS and very minimal JS modifying the zoom-levels.
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.
This is more of an alternative to SVG than an alternative to JS. You could always create charts using plain SVG. Most JS charting libraries just do that for you.
I don't feel like they're far off here.
The legend piece looks promising, they just need to be able to label both the axes, and I think you've got everything you need.
I've experimented with this myself. You can get some nice interactions by using checkboxes and radios instead of list items, but you would need something to hook onto the table row or cell, a class or a data-attribute.
Agreed, I kept looking through all the examples for labelling of both the axes. It's a bit strange that you would not show the number one thing most people are looking for in a chart.
From the looks of it you can put all the data in a table element without having to use javascript. If it was pure SVG you would have to mix the data and presentation, and it would make accessbility trickier.
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.
The advantage is that you write HTML/data and get a nice chart, whereas with SVG you need something to process the data, either in the browser with JS or locally with any graphing tool.
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)
Seems like it could be a good option for super simple visualizations without having to rely on something heavier like D3.js (which I personally love using)
1. Is this substantially faster than JS? (canvas / .svg). Please test this exhaustively. Render time and script evaluation for JS charts is still a huge JS problem.
2. Can this be made interactive, e.g. on mouse-over show exact numbers? Without interactivity, it is still kinda lame
2. You could use the title attribute to accomplish this. The example for mouseover contains a span tag that probably mess it up for a screen reader read so it reads it out twice. Might happen if using the title attribute as well.
Yeah, it can be a flip depending on implementation, whether you can beat something that is just pixels and GPU with the DOM + browser rendering engine, which has more layers and unpredictability.
This is beautiful work! I would love to see more interactive charts though (albeit it might already be possible with some tweaks). For example hovering over data points on line chart could pop a data point label or something similar. Amazing stuff, nevertheless.
Edit: My bad. I misread the parent comment. My original response preserved below for posterity.
- - -
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.
Last year I also released a barebones chart maker using only web components [0]. Meaning you can add a chart to your webpage with just an HTML tag. [1]
The functionality behind this and others are simple and allow the user to fully stylize however they'd like.
Amazing project! This will be very practical for my Blazor application. It's a nice way to prevent ugly JavaScript interop wrapper for charting libraries :-)
This is just what I needed. Currently using echarts-vue for a personal project but it's just too hard to use for what I need it for. Too bad this doesn't have pie charts yet.
This is awesome for sparklines and lighter weight visualizations. The animated donuts had me hoping there would be a pie / donut chart too! Would love to see that.
Tangential comment: I’m on a phone and can’t look deeper into this site for sometime. I’m impressed with how fast the pages load from different links within this site. Anyone know or can describe the internals? Thank you, kind person.
Looks good but not practical to use. I would love to see some JS support through which I can feed in data. Looking at documentation, I did not find how can I feed data. Looks like I have to calculate it manually or hardcode it.
If I missed something, can you point me to the right place in documentation?
That's something that would make this useful.
You are misunderstanding the technology in play here. This is just HTML, rendered by CSS to look like a chart (if I understood correctly). If you want to change the chart just update the HTML data table that's rendered as chart with JS.
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.
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.
This is absolutely practical. Especially with pages with a large number of chart elements. Using larger libs for parklines is impractical. I can totally seeing this being able to extent to the type of chart you would typically put in a PowerPoint.. And how practical is that. Sure not full js charts like amcharts and co, but libs like that ships with 90% of code which 90% of users do not use (sure I’m exaggerating here).
It is an amazing proof of concept. Just think of the possibility to easily draw Charts without SVG and the need of JavaScript. There are still some niche use cases for JavaScript disabled browsers.
Marketing pages always love to have big pretty bar charts to compare whizbang product with the old standbys. This would be great to make a big hero chart that looks good, doesn't need any javascript, and has amazing SEO (the raw table data is slurped down by google indexing).
These don't display at all in Internet Explorer 11. You either get a white square or a series of unreadable numbers.
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.
Best way is to chekc for IE11 in JS and display an error message to the user to use Edge/Chrome/FF/etc. That way at least you don't present something broken to the users.
Since I couldn't easily find how large it was and wanted to try it out at the same time.