Interesting the author mentions he is inspired by MVP.css[0]. I am in the process of changing my home page yet again to remove the current CSS framework I used. No more classes. After a few months not touching my site I find don't understand my own web site. Interestingly I still remember HTML elements I learnt in late 90s. I am sticking to styling HTML and will use one of the minimalist CSS frameworks that have been popping up on HN[1][2] of late. I see this can be used with pandoc, I just installed pandoc yesterday to see if I should use pandoc as my static site generator. Look forward to trying this out.
I'm just wondering how the line chart is actually more accessible than an inline SVG of the same chart. You go through a lot of trouble creating lots of <div> tags, but you could also just emit an SVG with ARIA annotations (or alternatively some hidden HTML that is read by accessibility tools).
Agreed. This is nice work. Recently dropped in Chart.js for an internal rails application to throw up some charts for users to get a better view of their data on their dashboard and they were blown away. A few simple bar charts and graphs can do wonders.
Good point about the line chart. There are a few other ways I considered as well: using a clip-path to make an area chart, or using borders of rotated divs for each segment. I had not seen it done with background gradients the way I did it, and honestly I wanted to try it that way and got caught up in it. I may revisit the other methods and see if I can make something simpler.
The markdown generation in ingenious. This will integrate well with static site generators, and the charts are extremely lightweight.
I posted a Show HN a while back for charting project that is also minimal (zero) dependency, in a sense: https://github.com/typpo/quickchart
It's a web service that takes a Chart.js config and renders the chart as an image. Downsides compared to this: not accessible, not as lightweight. Upsides: works in email clients (most of which disable flexbox) and other embedding situations, more customization via Chart.js
Thanks for sharing this, I like this idea a lot. I had been playing around with using whktml to make image files out of the ChartSS.css charts for situations that require them. Having a web service like this is a cool solution.
I like that and might use it for my markdown note-taking app.
However, it seems that there's an alignment issue between the axis' values and their points (or bars) on the graphs. The stacked bars total value is 95, yet it seems to go a bit over 100, and the problem is even more apparent on Line and Scatter plots. Nothing too major to fix I guess.
The non rounding on axis values (0, 20, 39.9, ... 99.8) is also a bit weird. Sorry I don't want to sound negative, I'm really interested and will keep an eye on it!
Thanks for the feedback - I agree that I need to do some work on how the axes scale and where the ticks go, and I see the bug you are talking about with the axis being greater than the sum. I think it is due to the placement of the tick. The very top of the axis is 99.8 but the label gets placed a bit lower so it looks like that. Will sort that out.
You don't have to override the template in the lua code to include the mvp.css file. use --css argument to set the location of the css file. it can even take multiple arguments (one for mvp.css and one for chartss.css).
In the current state, your "function Doc(" block upsets existing pandoc workflows.
Edit: didn't want to sound harsh with only the criticism :) Thank you for showing how to use lua-filters to do really cool stuff. I've playing with lua-filters, but your code is a clear example of how to extend markdown with a mini-DSL.
Edit 2: Sent you a PR on github with what I was suggesting here.
That made me laugh, but the scale on the y-axis is odd. The inputs are all integers but the generated tick labels are floats (e.g., <span class="TickLabel" style="--tick-label:'99.8'"></span>).
One job I got into some fights with marketing and our "design experts" over this because they decided the marketing image of the company was "light and airy" and so they wanted an ultra light font weight everywhere. It was their branding font they wanted for both headers and body text. (The were so focused on ultra-light fonts, to the point where they were even trying to get rid of the option to use strong text in the middle of paragraphs. If Outlook/Word allowed a group policy to disable the Bold button, they'd probably have taken it away. Haha.)
It took a lot of convincing that a software developer would know basic typography enough to know it was a bad idea, much less was I able to convey that it was an accessibility nightmare. I had to use some CSS tricks to get that work done and psychologically "show" that things were still "light and airy" while using reasonable font-weights for body text, and in the end they still didn't entirely believe me about the accessibility issues.
I guess you are talking about user stylesheets and not user agents. Yes, they could but there's a lot of lightweight fonts you'd have to hardcode.
Also that's not possible on (most) mobile browsers and it shouldn't be something people have to do just to be able to read something in the first place.
Love the syntax 10 out of 10. Visual design wise it’s not bad, but could be better. If I have some time I would love to contribute some add-one people could use for a different theme of designs.
Why do people do this? If you're going to bother to make a project public with a big page demonstrating what it can do, why would you skip the part where you tell people how?
It really comes off as amateur. I have other things to do with my time than reverse-engineer your code.
It really comes off as amateur. I have other things to do with my time than reverse-engineer your code.
Perhaps the authors, who were generous enough to share the results of their work, have better things to do than to handhold you through review of their work.
Then their work probably isn't worthwhile to adopt, given the plethora of alternatives. If their time is limited so that no documentation is produced, dropping bugfixes seem to be next (IME).
Unless those authors are specifically trying to get you to adopt their work for whatever reason (sales, good will, etc) and in which case they'd likely have documented it, you are not doing them a favor by adopting their work. You're just benefiting from what they've released.
It's like going to a free buffet and complaining there's no napkins. Sure, you can complain, and you're technically correct that there should be napkins. But it's still in bad taste.
If there is no desire to have adoption, then there is no compelling reason to host publically outside of convenience. We fundamentally agree, I think, with the difference of our thought being that we have a "show hn" post (I assume from the author?) which is an invitation to test, critique, and or adopt. Of course, the OP's relationship to the author flavors this expectation, and I could be in error.
> If there is no desire to have adoption, then there is no compelling reason to host publically outside of convenience.
I get the sentiment, but please don't listen to advice like this. I have benefited multiple times from small Open Source projects on Github that were essentially abandoned and undocumented. Sometimes just having source code is enough. More than one of the projects I'm currently working on are essentially just forks of permissively licensed, undocumented projects that I found on Github.
Yes, documentation is very important if you want an actual professional project that lots of people can use. But I generally encourage people to get into the habit of just releasing stuff. A permissively licensed project with no documentation on Github might end up benefiting at least one or two people. Maybe it won't benefit anyone at all, but at least the possibility is there. A project that never gets released to anyone is guaranteed to benefit nobody except the original maintainer.
In general, people are bad at determining what parts of their work have value. People worry about drowning Github in tiny or unfinished trash-projects, but my experience has been that it is much easier to filter projects than to find projects.
If I have a problem, I can spend 2 hours filtering through bad solutions and reading source code until I get at least a picture of what a solution might look like. That'll be more enjoyable than spending 2 hours scrolling through unrelated blog posts or desperately trying to come up with search terms to find anything anywhere that's applicable to what I'm trying to do.
You know what, that is a completely fair assessment and a fantastic take. Edit period has passed, so I'd revise my prior stance to be clearer that my point wasn't advice, but more general motivation/driver assessment. In terms of what benefits society as a whole, I agree with you completely.
I get where you’re coming from. Just know that at least in Germany, no company will ever use or support your library/product publicly with a name like that.
If you don’t care, that’s fine.
[0]https://andybrewer.github.io/mvp/ [1]https://github.com/dohliam/dropin-minimal-css [2]https://news.ycombinator.com/item?id=23220081