Hacker News Reader

Comment by bob1029 | Hacker News Reader

100% agree. CSS-only solutions are extremely attractive. Avoiding use of JS entirely is one my team's core values at this stage.

We never got rid of 100% of it, but we did get really damn close using Blazor. Only ~180 lines of javascript interop is required for our entire solution last time I checked. This isn't trivial stuff either... We hand-rolled large file upload/download w/ progress, get client rect, get/set cookies, etc.

View on HN

Perhaps I'm wrong, but it may be impossible to add zoom capabilities to charts without JS

Hmm. You would probably want to implement the actual zoom as a `transform: scale() translate()` regardless, and you could parameterize it with CSS properties like `transform: scale(var(--zoom-scale)) translate(var(--zoom-x), var(--zoom-y))`. But when it comes to getting those numbers and hooking them into the CSS vars, I don't see a way to do that without JS. Certainly, though, the JS could be just a couple lines if you did things this way (mousemove listener on the container, a bit of math to get the relative x/y, and then either a slider or a scroll listener to determine the scale, and these three numbers are plugged directly into the CSS).

Yeah, I suppose are definitely ways to do some basic zoom with just CSS and very minimal JS modifying the zoom-levels.

But then when you take into account data that needs to be inserted for higher resolution at higher zoom levels, it becomes a lot of JS, especially if that data needs to be fetched as the user zooms.

It can definitely be done with checkbox hacks, adjacent child selectors, transform, and scroll-based interaction to pan.

You could probably use the :hover: pseudo-class and make it work.

That would assume a single, harcoded zoom level and position

use js + scroll-wheel observer, profit.

For what project/company?

I am under NDA on specifics. We build automation/workflow solutions for the financial sector.

Reply on news.ycombinator.com