Re: correct and incorrect uses of canvas

On 7/16/2011 7:27 PM, Andrew Fedoniouk wrote:
-----Original Message----- From: Kornel Lesinski Sent: Saturday, July 
16, 2011 4:15 PM To: Andrew Fedoniouk Subject: Re: correct and incorrect 
uses of canvas
On Sat, 16 Jul 2011 18:42:42 +0100, Andrew Fedoniouk 
<andrew.fedoniouk@live.com> wrote:
>>> SVG has performance issues by its generic nature.
>>
>> Assuming that browsers aren't able to take advantage of SVGs 
>> declarative nature and native implementation to their advantage (e.g. 
>> cache rendered parts of DOM that doesn't change, GPU-accelerate 
>> animations, avoid cost of reading rendered pixels back from the GPU).
>>
>> In cases where scene graph is needed, a <canvas> solution won't 
>> necessarily be better performing — authors might just roll their own 
>> SVG-like solution or use a library (e.g. fabric.js) that gives up 
>> possibility of very specific optimisations and has to work with scene 
>> graph in a high-level language and has no direct control over the GPU.
>>
>
> My points are simple:
>
> 1. there are few tasks where SVG is better and there are task where
> <canvas> is significantly more optimal.
> 2. A11y of SVG is rather theoretical than practical - it is too low 
> level for
>   that.
> 3. Neither <canvas> nor <svg> have acceptable a11y value. <svg> and 
> Graphics
>   shall be used only as images in CSS or content of <img>. 

Kornel,

Authors who use libraries are able to hack those libraries if they like.
That's a very practical situation. With SVG, authors are either all-in
or they have to re-implement. If a UA doesn't support the scene,
then the author is pretty well out of luck.

For direct control of GPU, we've got CSS transforms for the most
basic of GPU tasks; and WebGL on some UAs for more advanced tasks.

Largely, author solutions can be tuned to the data they're using,
and vendor solutions are more generic.


Andrew,

SVG accessibility is not well implemented, and was not fully thought out 
within the SVG 1.x specs,
but there are enough rich semantics with ARIA 1.0 applied to SVG to 
bring it in line with most of HTML.

ARIA 1.0 did not target SVG, I'm sure the next version will explore new 
concepts.

Authors and UA vendors have not really hooked ARIA into SVG documents.
Few ATs use SVG data. ViewPlus is one AT vendor that does do basic use 
and reading of title tags.
I'm sure there are other non-browser SVG implementations that have 
explored accessibility of SVG.

I'd like to know how you are qualifying this: "Neither <canvas> nor 
<svg> have acceptable a11y value".

I've been working for quite some time to explore and address defects in 
<canvas> a11y, and I intend
to carry on and explore defects in SVG a11y. Presently, canvas 2d in the 
w3c spec does have excellent
a11y value, but it is missing a method to represent bounding boxes and 
paths to platform accessibility APIs.

Let me know what kind of a11y qualities you're looking for, and I'll 
respond with technical
information on how to accomplish them with canvas, and what semantics 
may be needed (or should be supported) for SVG.


-Charles

Received on Sunday, 17 July 2011 02:46:19 UTC