I’ve been using a similar technique to display our poll data[1] for several years, although without using grid. If you can measure the text because you know which font will be used, and store the widths of various characters, you can take a little more control over layout too, even while rendering server-side.<p>I also started writing a simple responsive SVG charting library[2], but the author is right in that there are some fluid layouts that are just impossible to realise with SVG at the moment.<p>[1]: <a href="https://poll.lowyinstitute.org/report/2024/global-powers-and-world-leaders/" rel="nofollow">https://poll.lowyinstitute.org/report/2024/global-powers-and...</a><p>[2]: <a href="https://stephenhutchings.github.io/shown/" rel="nofollow">https://stephenhutchings.github.io/shown/</a>
Making charts (of any kind) accessible is a really hard endeavour. I watched the demo videos and if I’m allowed to make a suggestion... Add the context to the data points. A simple “50k” might not cut it for people navigating the plot with their fingers over a smartphone.<p>Full disclosure: I worked with those peeps a decade ago and really love their work.
> In SVG, all shapes are absolutely positioned. Text does not wrap automatically.<p>This is not really true — you can position elements inside the SVG coordinate system using percentages and you can mix absolute coordinates and percentages. This allows you to have elements grow and shrink in reaction to width and height without distortion.<p>Wrapping text is possible with <foreignObject>, simply let HTML/CSS do the text layout wherever you need text within the SVG.<p>However it is still true that you usually want to do a bunch of calculations in JS based on the width to know how many chart ticks you want, how many labels, etc. But that is pretty easy to compute with the helpers from D3.
Actual live example of said charts: <a href="https://codepen.io/molily/pen/JjqgxVR" rel="nofollow">https://codepen.io/molily/pen/JjqgxVR</a>
I like the work, it looks good and (probably) works well, but there are some assumptions here that are off:<p>> When the container size changes, for example due to a browser resize or orientation change, the JavaScript needs to compute all SVG positions and sizes from scratch. Assuming this takes 50-100ms per chart, a page with 20 charts freezes the browser for 1-2 seconds.<p>I was once calculating positions for some complex labels on a timeline like chart (e.g. you have two entries close to each other and you would align the labels left and right to fit, but if there more you needed to stack them etc) and it did not take 50-100ms even for hundreds of entries. My code was neither pretty nor very efficient. Their 5-10 data points especially would not take that long. But even then you can always calculate them one by one and not block page interaction.<p>In addition people don't really resize their browsers that much anymore, if they ever did. The majority of traffic is mobile and there even the occasional phone rotation is not really that common, especially not for reading articles.
"While responsive and accessible SVGs are possible, they require manual client-side JavaScript logic"<p>an oxymoron, given that many assistive devices don't run JS [eg text-browsers like lynx]