- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 12 Jul 2011 13:13:23 -0700
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: HTMLWG WG <public-html@w3.org>, Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>, David Singer <singer@apple.com>, "Edward O'Connor" <hober0@gmail.com>, Canvas <public-canvas-api@w3.org>
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