W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: correct and incorrect uses of canvas

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Wed, 20 Jul 2011 09:54:58 +0100
Message-ID: <CA+ri+V=8fN4eJUx2J2=+EcUTgf-5OQy2QrVSN8osJGJpBEe2Ow@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@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>
Hi Tab,
it would be useful if you could respond to the email I sent a little over a
week ago (below) email, as you are one of the more vocal opponents of
providing a method to make canvas accessible due to the use being better
done using SVG.


also what are you thoughts on Jonas' email on this thread?
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html

in which he states

"I do think we need to add some sort of API which lets you declare a region
on the canvas which can be used for hit testing. Possibly do that by being
able to associate a region with an element in the contained DOM inside the
canvas. This would also integrate well with things like screen magnifiers
zooming in on the correct region of the canvas when the relevant node in the
contained DOM receives focus. Ideally setting the area covered by one of
these regions should be easy to set while performing one or more drawing
operations."


regards
stevef

On 12 July 2011 22:14, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> Hi Tab,
>
> both of the object drag and drop you said are examples so can't be judged,
> let me put 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
>
>
>


-- 
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
Received on Wednesday, 20 July 2011 08:55:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:26 UTC