Re: correct and incorrect uses of canvas

Tab,

You've looked at a variety of Canvas applications, at this point, dozens.

All of your responses demonstrate that you believe the applications
can be implemented in SVG, and that you believe doing so would be "better".

Your qualifications for "better" have been around things being "automatic",
as the code paths are handled by the UA instead of being included
as libraries in the scripting environment, and svg documents are highly 
formal,
allowing for deep introspection.

You've noticed that the formality of SVG documents may lead to them being
more difficult to author than canvas; you have also noted that scripting
libraries may solve this issue.

Am I hearing you correctly?

I do see that you've reviewed many Canvas apps and stated that
they "would be better done in SVG", that authors should "use SVG", and that
authors that use canvas are "doing it wrong"...

I can't help but again say: the list has brought forward dozens of 
examples of Canvas applications
which could be more accessible to users of assistive technologies such 
as ZoomText
and Apple's VoiceOver for Mobile Safari, with the inclusion of one 
method call.

I've shown you that method call in use for a clickable text region, it 
was simple,
you understood it.

You have expressed a strong belief that authors should program in SVG
and do less programming Canvas, especially in relation to UI elements.

That's fine, but there are many thousands of Canvas apps on the Internet 
today,
there are many hundreds of Javascript libraries which support canvas.

Leaving out critical accessibility methods has the consequence that
some users may not be able to access the apps, even though the authors
are willing to spend their time testing and supplying data for those 
methods to work.

I've replied further in-thread.


On 7/12/2011 1:13 PM, Tab Atkins Jr. wrote:
> On Tue, Jul 12, 2011 at 12:28 PM, Steve Faulkner
> <faulkner.steve@gmail.com>  wrote:
>> 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.
>
>> 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>.
With SVG or Canvas, a "decent api" would make any project easier.
In this case, the "decent API" is the processing language. The example
could certainly target SVG, but it'd be a chore and there are many
SVG implementations to test.

It looks like you -may- agree with Jonas Sickling's assessment that 
there are
processing.js examples that can serve as an acceptable use case of Canvas.

http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html
"In particular, one situation which is common, and is likely to remain 
common, is JS libraries, such as
processing.js which output to canvas. We can and should improve the SVG 
DOM to attract more people, but I suspect there will always be a
group of people that choose to use canvas anyway due to better 
performance or other reasons."

>> Visual Knowledge Browser
>> http://askken.heroku.com/
> Definitely better for SVG.  Text and hit-testing everywhere.
Hit testing is not particularly difficult.

>> 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.
>
>
>> 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.
The directory structure can be reflected in the DOM regardless.
And using ARIA semantics, the entire structure does not need to be 
present in the dom at one time.

There's no particular reason why the text can not be present in that 
structure.
Implementing this in SVG, I'd still likely to have an HTML representation
of the content, with list item or table semantics.

Sure, I'd try to have this work in HTML, Canvas+ARIA and SVG outputs,
instead of deciding which is "better". But I would certainly start with 
Canvas,
as I can reach more devices with it, then I would turn to SVG and work 
on UA testing
and deciding what ways to gracefully degrade.

>> 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.
Scripting libraries are available to make it just as easy in Canvas.
This is similar to your qualification: "probably be easier ... with a 
decent API".

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

The second use case is progressive enhancement, same thing we do with CSS.
Even when there is not an existing HTML element, we still ought to be 
wrapping
some kind of semantic markup or including at the very least, an anchor 
reference.

Yes, one of the uses of canvas is visual, presentational enhancement.

-Charles

Received on Friday, 15 July 2011 02:33:01 UTC