Live data from Hacker News

Easy SVG sparklines

alexplescan.com

81–90 of 106 posts

Re: Easy SVG sparklines

#81
post #61

Earlier quoted context omitted.

Canvas is just a pixel buffer. Even with sufficient caching SVG would be slower because there’s more work to do with parsing, etc.

Canvas is a pixel buffer... and a set of drawing rudiments to imperatively actually make that pixel buffer useful. If you were actually just using canvas as a pixel buffer it would be catastrophically slow. SVG is a pixel buffer and a set of drawing rudiments to imperatively or declaratively actually make that pixel buffer useful. The distinction you are drawing between these is sophistry.

SVG is a pixel buffer the same way html is a pixel buffer. It can have multiple types of animations, hover states, etc.

Re: Easy SVG sparklines

#82

Maybe it's just because I have so much experience with design and visual art, but I think SVG is one of the most, if not the most underutilized web format. It's great for the self-contained static vector graphics that it's most commonly used for, but it can do so much more. SMIL animations can be a little clunky, but having an alternative to gif and video that doesn't require JS is pretty rad-- especially for throbbe…

Totally agree. I bookmarked this guide that hit the top of HN a few weeks back, a good primer on how to get started manually programming paths, which unlocks a lot of cool dynamic SVG and animation opportunities: https://www.nan.fyi/svg-paths .

I try to keep my SVGs simple, and often tweak them by editing the XML data in a text editor. (Linus Torvalds relaxes with assembly language, I make image files smaller...) https://www.phoronix.com/news/Linus-Torvalds-Relax-Inline-AS...

This simple iOS app helps me play with path changes, sort of a unit-test use case for me:

http://genhelp.com/apps/svgpaths.html

Re: Easy SVG sparklines

#83
post #61

Earlier quoted context omitted.

Canvas is just a pixel buffer. Even with sufficient caching SVG would be slower because there’s more work to do with parsing, etc.

Canvas is a pixel buffer... and a set of drawing rudiments to imperatively actually make that pixel buffer useful. If you were actually just using canvas as a pixel buffer it would be catastrophically slow. SVG is a pixel buffer and a set of drawing rudiments to imperatively or declaratively actually make that pixel buffer useful. The distinction you are drawing between these is sophistry.

No the distinction is important and directly related to performance. Supporting the canvas API requires fewer CPU instructions to get to pixels on the screen. The browser has to do a lot more work to turn SVG into pixels

Re: Easy SVG sparklines

#84
post #14

This is cool! For those who don't know, there's a font called Sparks that uses glyphs to create sparklines: https://github.com/aftertheflood/sparks

Recent HN thread on another "graphing data" font, although this one doesn't simply map numbers to graphic, prompting a discussion on accessibility issues to consider:

Datalegreya Font https://news.ycombinator.com/item?id=25832196

Re: Easy SVG sparklines

#85
post #14

This is cool! For those who don't know, there's a font called Sparks that uses glyphs to create sparklines: https://github.com/aftertheflood/sparks

all their examples and URLs (save for the code itself on github) but even the font files themselves are dead because that company closed in 2020 :/ Very neat idea, though! I did find this example: https://observablehq.com/@tomgp/sparks-with-live-data For those examples to work (which they still do), the URL references to the font data in the stylesheet should ostensibly still be valid: https://tools.aftertheflood.com…

Apparently, the host 'tools.aftertheflood.com' is still mapped to GitHub Pages.

Backing out from the CSS file (many thanks!), turns out the top-level web page is still up -- BUT the links to download the zip file font collections DONT WORK.

So you still need to scrape the CSS file to get working links to the individual fonts... (I was going to post those URLs here, but there are 84 of them. Use a command like this to scrape the CSS file:

   grep -o "http[^']*" 
However, this GitHub Pages site still hosts web pages that show some great examples and links to ObservableHQ notebooks (which also still work, hosted at observablehq.com).

https://tools.aftertheflood.com/

Re: Easy SVG sparklines

#86
post #49

Cool explanation! I use quite a lot of SVG visualisations generated server-side. Some basic charts (including sparkline) are bundled up into ContEx (an elixir library) - see https://contex-charts.org/ (disclosure - author).

Thanks! And thanks also for your work on ContEx, its Sparkline module [1] was a big inspiration for what I ended up implementing.

[1] https://github.com/mindok/contex/blob/master/lib/chart/spark...

Re: Easy SVG sparklines

#87

Maybe it's just because I have so much experience with design and visual art, but I think SVG is one of the most, if not the most underutilized web format. It's great for the self-contained static vector graphics that it's most commonly used for, but it can do so much more. SMIL animations can be a little clunky, but having an alternative to gif and video that doesn't require JS is pretty rad-- especially for throbbe…

Funny you say this, I spent a good 5+ hours yesterday trying to get an SVG of a UI mockup to render properly on Safari before giving up and implementing it in HTML.

What was especially annoying was that different representations of the exact same SVG would behave differently (inline-svg vs img+src vs object)

Re: Easy SVG sparklines

#89
post #14

This is cool! For those who don't know, there's a font called Sparks that uses glyphs to create sparklines: https://github.com/aftertheflood/sparks

all their examples and URLs (save for the code itself on github) but even the font files themselves are dead because that company closed in 2020 :/ Very neat idea, though! I did find this example: https://observablehq.com/@tomgp/sparks-with-live-data For those examples to work (which they still do), the URL references to the font data in the stylesheet should ostensibly still be valid: https://tools.aftertheflood.com…

oh that's a bummer, didn't know that killed the examples and links to the font files :(

I just created a new issue and uploaded a zip file of their fonts to their Github: https://github.com/aftertheflood/sparks/files/12009401/AtF.S...

(Finally a justification for my font hoarding)

Re: Easy SVG sparklines

#90

Maybe it's just because I have so much experience with design and visual art, but I think SVG is one of the most, if not the most underutilized web format. It's great for the self-contained static vector graphics that it's most commonly used for, but it can do so much more. SMIL animations can be a little clunky, but having an alternative to gif and video that doesn't require JS is pretty rad-- especially for throbbe…

Funny you say this, I spent a good 5+ hours yesterday trying to get an SVG of a UI mockup to render properly on Safari before giving up and implementing it in HTML. What was especially annoying was that different representations of the exact same SVG would behave differently (inline-svg vs img+src vs object)

SVG has… weirdnesses. I couldn’t say exactly what they are. But it feels like an older format from an XML-centric era. It also feels fairy lax on “optional features” and ambiguous spec (although I’m not sure this is true). There are noticeable differences between different rendering engines.

Most of drawing works fine as markup. However, animations and simple state changes are awful. CSS is much easier to use for some of those purposes.

I’d very much forgive SVG for its clunkiness, after all it’s old yet very powerful today. It’s a prime candidate for a revamp.

Post reply on HN