<div class="s-m c-5 m-20 pl-10 ma ta-l">
<p class="fw-b lha mt-4 c-2 f>Hello, World!</p>
I MVP looks cool, will check that out
I love the simplicity of the bar charts.
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).
I would assume it would just treat it as an image.
Url is https://rbitr.github.io/ChartS.css/
It refers to itself as C:greenheart:SS.css (what?)
Aka ChartSS.css - clever, but neither descriptive or memorable.
Edit: The fact that I can't even rag on the name in the comments due to the emoji makes me feel more justified in my original assessment. :P
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
Curious, how do you rate limit? IP address?
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!
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>).
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.
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.
I'm a real sucker for simple markdown text that can be turned into something that non-technical folks can find appealing.
Experimental, pre-release: https://pancake-charts.surge.sh
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.
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.
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.
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.
Documenting > Orphaning > Not Releasing
Experimental charting library for Svelte
If anything, it's more amateur to document an experimental API you know will be continually broken until a stable release in the distant future.
They don't want people to start relying on it.
It seems absurd that a two letter combination not used for nearly a century is enough to disqualify a name on an entire continent.
We won. It’s over. We can reclaim their terms and symbolism now.
It's even funnier because the Islamic State uses lots of Toyota Hilux