Re: correct and incorrect uses of canvas

On Tue, Jul 12, 2011 at 12:28 PM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> hi all,
>
> Accepting that text editing in canvas is not a good idea and buidling
> traditional complex UIs in canvas is not a good idea.
>
> Is the use of interactivity in canvas appropriate in any circumstance?

Yes, of course it is.


> For example are the following correct or incorrect uses of canvas?
>
> interactive graph
> http://thejit.org/static/v20/Jit/Examples/ForceDirected/example1.html

This would be better done in SVG.


> drag and drop, resizable objects
> http://kangax.github.com/fabric.js/demos/customization/index.html

This is a set of programming examples, not an application, so it cant'
really be judged.


> UI Dial With Snaps
> http://bocoup.com/processing-js/docs/?page=UI%20Dial%20with%20Snaps

Toss-up.  It would probably be easier in SVG with a decent API, but
there's not much to it.  This falls into the "make an element
prettier" use-case, which is solved decently by <canvas>.


> Visual Knowledge Browser
> http://askken.heroku.com/

Definitely better for SVG.  Text and hit-testing everywhere.

> Handling Click Events On Chart
> http://www.deensoft.com/lab/protochart/clickevent.php

Probably better in SVG (line-drawing with markers at the joints is so
easy!).  That would keep the text around.


> drag and drop
> http://easeljs.com/examples/dragAndDrop.html

Tech example, so can't really be judged.


> Sumon WebGL (2d canvas animation fallback)
> http://labs.hyperandroid.com/sumon-webgl

Toss-up.  This could be implemented directly in HTML if you didn't
care about polish, so it probably falls into the "make an element
prettier" use-case.  It could also be done in SVG pretty easily, but
I'm not sure how easy it is to get the level of visual polish they're
aiming for.

(I can't actually play it - I get 1Hz or less framerate.)


> Sunburst of a Directory Tree
> http://thejit.org/static/v20/Jit/Examples/Sunburst/example2.html

Better done in SVG.  Lots of hit-testing and text, plus the actual
directory structure could potentially be reflected in the drawing
tree.


> letter pair analysis
> http://www.m-i-b.com.ar/letters/en/

Better done in SVG - it's just circles filled with text.  SVG would
handle the scaling and positioning more easily than doing it by hand
in Canvas.


> If  the above are not considered misuses of canvas, does the current canvas
> 2d spec provide the means to expose the required information to make the
> above accessible to users of AT?
>
> If they are misuses of canvas how can we convince developers not to use
> canvas in these ways?

There are two distinct classes of uses here that would be better done in SVG.

The first is just the ones where it would be much easier to do in SVG
than in Canvas if you programmed directly to the bare API, but the
library wrapped around Canvas makes using it as easy or easier than
using SVG.  We can fix this by making a better SVG API that's actually
easy to program to.

The second is where the basic use-case is making an existing HTML
element prettier.  In some cases (like the dial with snaps) this isn't
too hard (just wrap a <canvas> around the element in question, which
would probably be a <select> in this case).  In others (like the Sumon
game), it's quite a bit more difficult, because the elements you're
making pretty are all over the place.  You can't really wrap a
<canvas> around a <td>.  This needs some more analysis, because there
are a few different ways to potentially address this.


On Tue, Jul 12, 2011 at 12:38 PM, Charles Pritchard <chuck@jumis.com> wrote:
> There was some debate about remote access being a reasonable use case, as
> well
> as debate about whether the rendering of other non-web/legacy formats
> qualified as a reasonable use case.
>
> Is the support of legacy code an acceptable use case?
> https://github.com/kripken/emscripten/wiki
>
> emscripten runs LLVM byte code, and -necessarily- uses Canvas for painting
> output.

Unfortunately, along with remote access, that's a use-case that
basically requires porting an entire low-level accessibility API into
Canvas, and thus is something that's probably very low-priority, as it
won't ever be used by regular authors, just the occasional large corp
with a bunch of money and time to spare (or pending lawsuits hanging
over them).

~TJ

Received on Tuesday, 12 July 2011 20:14:22 UTC