Re: correct and incorrect uses of canvas

Hi Tab,

both of the object drag and drop you said are examples so can't be judged,
let me out it another way. Is the use of drag and drop and resizing of
objects in canvas OK in any circumstances?

such as this example:
http://www.ernestdelgado.com/public-tests/canvasphoto/demo/canvas.html

most of the other examples you have said would be better done in SVG.

So are these examples of incorrect use of 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?

regards
stevef

On 12 July 2011 21:13, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html