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.

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.

[1]: https://poll.lowyinstitute.org/report/2024/global-powers-and...

[2]: https://stephenhutchings.github.io/shown/

> If you can measure the text because you know which font will be used

If you are using text, you can’t know which font will be used. There are no universally-available fonts, so web fonts are the closest you get, but they could fail to load for various reasons, and it’s honestly more common than people allow for. You can also block web fonts (e.g. uBlock Origin has an entire button for it), or just turn off font selection altogether, in Firefox via Settings → Fonts → Advanced → untick Allow pages to choose their own fonts, instead of your selections above. I did this four years ago as an experiment and have never gone back because it made the web so much better (I did switch back for one week a couple of years ago to convince myself the web really was that awful without it). Not many people will do this deliberately, but it is a thing.

You could embed your web font inline to the stylesheet, as base64 encoded data url.

    <style>
      @font-face {
        src: url(data:application/font-woff2;charset=utf-8;base64,...) format('woff2');
      }

Your page loading times will obviously take a hit, but that'll give you pretty close to 100% certainty that the font will be used, should you want that.

That resolves one of the main causes of failure, and I generally speak very highly of inlining everything—it has very noticeable performance benefits up to surprisingly large sizes (generally well over 100KB).

Aside, pairing application/font-woff2 with charset=utf-8 makes no sense. It’s a binary encoding.

But I think you’d still be surprised how many browser configurations don’t load web fonts, though I’m sure it’s becoming less common.

Knowing which font is used with a hundred percent certainty, maybe not. This probably is something more people should be aware of. But the failure mode might be some slightly awkward line breaks, assuming you allow for the edge case of alternative fonts. And even when the calculation isn’t a perfect representation of the rendered reality, the approximate width is still more useful for layout purposes than going in blind.

Combined with em-based sizing I’ve found this to be pretty robust. Just because you can’t make it perfect for all users doesn't mean you can’t do the work to improve it for many.

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.

Full disclosure: I worked with those peeps a decade ago and really love their work.

> Making charts (of any kind) accessible is a really hard endeavour.

Agreed! I've done a lot of experimenting with my canvas library to try and make accessibility a "first class citizen" in graphical representations, including charts. Things (I think) I've got right is to make it easier for people to use keyboard navigation to interrogate a chart, and making sure that graphical text gets properly copied into the DOM in an ordered way, and updates when the graphical text changes.

The main failure I face is getting screen readers to recognise that the graphical text exists/updates. For example, this chart demo[1] is responsive, interactive and keyboard accessible but, when listening to that page with VoiceOver on a Mac, there's a clear failure to get the current data point from the screen to the listener.

I know screen reader tech is the wildest of Wild Wests when it comes to front end. My only hope is that there's an easy solution to the issue, like I've badly misunderstood how screen readers work and the solution will be obvious when I stumble across the key errors I'm making ... and correct them!

[1] London crime charts - https://scrawl-v8.rikweb.org.uk/demo/modules-001.html

> In SVG, all shapes are absolutely positioned. Text does not wrap automatically.

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.

Wrapping text is possible with <foreignObject>, simply let HTML/CSS do the text layout wherever you need text within the SVG.

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.

Hello! Author here. When I say absolute positioning, I mean it in the CSS sense (as in position: absolute) to contrast it with CSS Normal Flow, Flexbox, Grid, Floats etc.

While it's true that SVG allows percent positioning and foreignObject with HTML inside, this does not help us for the task at hand: Positioning shapes/text in relation to other shapes/text. This is out of scope for SVG to my knowledge, while it's the natural domain of CSS.

Almost all of our charts have text labels of different size. In many charts, we measure the text with measureText() on a canvas first, then compute the SVG positions manually. Or we have HTML/SVG hybrids where we measure the text using getBoundingClientRect(). This two-stage measure/layout process is what we seek to reduce.

Actual live example of said charts: https://codepen.io/molily/pen/JjqgxVR

I like the work, it looks good and (probably) works well, but there are some assumptions here that are off:

> 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.

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.

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.

Why are all these responsive charts displayed as images? Are they not proud of their work?

I think responsive refers to data, not to mouse/user interactions.

Lovely!

An article about responsive bar charts without them? (Firefox)

I'm not hip enough to find this funny.

We live in an era where people will unironically tell you your article written in html/css might be a bit difficult to include on their website.

There's never been an era where that wasn't difficult for the majority of humans.

What's changed isn't that becoming harder, it's that hosting websites which don't need any understanding of html/css has become hugely easier and therefore done by far more people, including less tech-savvy people.

Somehow you're seeing that as a bad thing, focussing on the fact that the number of websites that are set up with the operator using html directly to create each page has decreased from 100%, but that's not actually a negative it's just the side effect of the positive changes!

(Sure there are some specific situations where a person who would be capable of using raw html chooses to use a CMS or something that does restrict them, but it only restricts them if they don't care enough to choose one of the millions of simple options for not having that restriction.)

Try to notice that your glass is more than half full, and that it's never been easier for anyone to create a website with the choice of manually writing hrml or not!

Easy page generators are definitely a good default which have enabled more people to create content (and not just recently, think myspace era and before) but the point wasn't "and it was better when you had to write HTML/CSS manually to have a page" rather "and these platform tools have started to elide the option to embed HTML/CSS when you want". This doesn't mean wanting to throw out the easy to use interfaces for a traditional CMS and writing everything out it means easy embeddability.

As an example think mediawiki and markdown. Each was designed to allow you to just make content, each has powerful GUI tools, and each was designed to allow direct embedding as needed. A lot of blog platforms have started to drop the latter bit for no gain in making the former bit more accessible than it would be otherwise.

Are you saying the interavtive code snippies are not what you want? This article is great and I've needed something like this in the past.

What do you mean that there are "without charts?"

The very first chart is a ‘bar’ chart running horizontally, not sure what’s missing (Firefox 127.0.2 64-bit). There are code examples down below….

It's an image. None of the charts are responsive charts in HTML and CSS.

I didn't even notice the CodePen at first because it doesn't load automatically (instead displays a cropped and zoomed image).

You are correct they are images besides the CodePen, I did not inspect them before commenting (hope the images is at least the output of the code). Guessing it must have something to do with the companies hosting platform tools and authoring code to it but have no idea why.

Almost all commonly used assistive devices support JavaScript, and have for years.

Lynx is not a commonly used assistive device.

“given that many assistive devices don't run JS [eg text-browsers like lynx]”

an oxymoron, given that many assistive devices don’t cooperate with any of the web or HMI accessibility guidelines at all [eg my wheelchair]