I've written about bar charts in HTML & CSS Grid and how they make responsive design, internationalization and accessibility easier than SVG & JS layouting.
https://9elements.com/blog/responsive-bar-charts-in-html-and-css/
Collaboration with @nilsbinder and @sphinxc0re.
Here's the link to the CodePen if you'd like to have a look at the final code:
@molily Removed .tick-line elements and moved the line as a pseudo element into .tick-value which is now a flex container that spans to the given --grid-row-count.
There also is no longer a need to define grid-template-rows. Giving the --grid-row-count is also optional, it defaults to spanning to a value of 100.
@molily Additionally this fork removes need for setting the inset-inline-start value for each .tick-value by using a flex container on .ticks:
https://codepen.io/Merri/pen/PorYvvE
(Edit: also switched to `visibility: hidden;` over `opacity: 0; user-select: none;`)
@MerriNet Thanks, many good improvements! Will look into them more deeply.
Regarding the ticks: The ticks numbers are nice and round (e.g. -100k to 100k) but the actual number extent is not (it might be -110,230 to 95,522, for example). There might not be ticks on the outer edges and they are not necessarily distributed equally across the width. That's why we can't use Flexbox here and need the explicit tick positioning (as far as I can see). Example attached.
@molily Here are more ideas to reduce output HTML size. No duplicated data, no absolutely positioned elements.
Removed the need to hardcode grid-row for each row, but it still needs --grid-row-count. Also the tick description height is hardcoded in CSS.
@molily Updated the bar chart pen above to clean it up.
- Got rid of --grid-row-count
- Fixes text selection appearance
- Customizable zero point
- Only need to pass min and max values as #CSS vars & #HTML attributes
The ugly parts:
- data-- needed to signal being below zero point
- The internal CSS max() trickery as CSS abs() is only supported by Firefox atm
- text-shadow CSS is a bit verbose way to achieve the -webkit-text-stroke effect, but necessary to fix the text selection visual issue
@molily Yeah, logaritmic values would need to be converted to linear values, but that is essentially the same as going for percentage values to represent the bar sizes.
For example, you could have -10000 to 10000 as the internal output values for CSS vars. And favoring integers just to avoid floating point number issues and the resulting verbose HTML output some of those floating point edge cases can cause.
molily
Vesa Piittinen
