Working with the native Canvas API is hard work
Particularly when the desired result is more complex than a couple of coloured boxes in a static display.
- Working directly with the canvas-related APIs leads to writing significant amounts of JS boilerplate code.
- <canvas> elements can be resized and styled using CSS, but changing the CSS size does not affect the element's drawing dimensions - leading to sub-optimal graphic displays.
- Events work on the canvas, not on the artefacts within the canvas - we cannot use artefacts as links or hot-spots (click/tap events), we cannot give them the equivalent of a CSS hover state (focus/blur events), we cannot drag-and-drop them around the display (move events).
- Tracking a user's interaction with the various parts of a canvas display is particularly difficult.
- We cannot save and share artefacts and effects; each canvas display is tightly coupled to the code that defines the display.
- Of most concern, canvases are entirely graphical - visual - by nature; they come with significant accessibility issues. Given the ever-stricter requirements for websites to be accessible to all users, this makes using a canvas to present important information a dangerous proposition.
But the benefits of using canvases for graphical displays and animations are also great
Libraries which attempt to emulate Flash-Actionscript animations have been developed, as have libraries whose aim is to combine 2D, 3D and even SVG graphics into a usable whole. Speed is a key goal for some of the best libraries, while ease-of-use is an objective for many others.
Scrawl-canvas overcomes the big barriers
Scrawl-canvas aims to be fast, and developer-friendly. It also aims to be broadly focussed, suitable for building infographics, games, interactive videos - whatever we can imagine for a 2D graphical presentation.
But the main purpose of Scrawl-canvas is to make the <canvas> element - and the parts that make up its displays and animations -