Ah yes I missed the var canvas line and just presumed the code was getting a context on the selected div instead, a feature I didn't know was possible (it isn't).
The canvas declaration is staring right at me now that I review it again. That's life...
My bad. Seems that a number of browsers block saving canvas elements as a security precaution. For now, I can only recommend trying a different browser as a workaround.
The article mentions why they couldn't use canvas for this: they are running this code in a worker, and canvas support in workers is not great in browsers so far.
The problem with using the canvas functionality for everything is that it's an all-or-nothing proposition, and you end up having to write a lot of stuff that is already handled by the browser, or can only be handled by the browser (think bi-directional text/NLS issues).
Using JavaScript to render to a canvas will work in all modern browsers, while maintaining (or even enhancing) the CSS's flexibility. I first thought the JavaScript solution would even be about the length of Moeed's CSS, but after writing it out my code's about 5x longer :(
you're still in the SPA. You generally need some sort of painters algorithm to repaint the canvas anyway. When the canvas comes back you would just repaint it from JS memory.
Canvas in particular has issues web devs have to deal with beyond their "normal" duties. Accessibility is simply not even a thing in canvas. Google Docs had to implement an entire parallel invisible DOM structure to emulate what they draw on the canvas when they were switching over to the canvas. And, of course, that DOM structure has to be in sync with canvas.
Awesome! Thanks for that tip. It hadn't occurred to me that that was possible, but, yeah, that makes sense.
I might pick my Canvas experiments back up, then, as R and the other packages are outside the scope of my day-to-day work, but I could see a JS implementation being useful. Thanks again.
reply