Responsive bar charts in HTML and CSS(9elements.com) |
Responsive bar charts in HTML and CSS(9elements.com) |
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...
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.
<style>
@font-face {
src: url(data:application/font-woff2;charset=utf-8;base64,...) format('woff2');
}
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.
Full disclosure: I worked with those peeps a decade ago and really love their work.
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
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.
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.
> 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.
I'm not hip enough to find this funny.
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!
What do you mean that there are "without charts?"
I didn't even notice the CodePen at first because it doesn't load automatically (instead displays a cropped and zoomed image).
an oxymoron, given that many assistive devices don't run JS [eg text-browsers like lynx]
Lynx is not a commonly used assistive device.
an oxymoron, given that many assistive devices don’t cooperate with any of the web or HMI accessibility guidelines at all [eg my wheelchair]
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.
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.