Re: correct and incorrect uses of canvas

>-----Original Message----- 
>From: Charles Pritchard Sent: Saturday, July 16, 2011 7:45 PM To: Andrew 
>Fedoniouk Cc: Andrew Fedoniouk ; Kornel Lesinski ; www-style@w3.org 
>Subject: 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".

This markup:

  <ol><li>...</li><li>...</li></ol>

has acceptable a11y value no matter how that list is rendered:
vertically, horizontally or either using absolute positioning.
Even without any additional efforts from author side.

SVG has no semantic constructs at all. Even we will have
some ARIA attributes for it the probability that authors will use them
is very low. Usually SVG is being created as any other image -
using WYSIWYG editors like Inkscape and the like.

Consider this SVG:
http://terrainformatica.com/w3/flower.svg

In HTML you can use that SVG for example as this:
<img src="http://terrainformatica.com/w3/flower.svg" alt="flower" >

We can  add to each <cicrcle> in that SVG attributes
@alt="leaf" or @alt="petal" but will it help to anyone?
If we will do this we will just create perfect noise/chaos.

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

As I said already: Neither SVG nor <canvas> have acceptable A11y
foundation (a.k.a. semantics ).
That is not because of "bugs" in them but because of their nature.
A11y opportunities in SVG or the canvas are close to other images
like PNG, GIF, etc. For PNG image you can automatically assign aria
attribute expressing pixel color. Will it help to anyone?

The solution (for the Graphics) is
1. to allow client side image generation using Graphics.
2. to allow use of such images as backgrounds in CSS so for any element.
3. to provide lightweight positioning mechanism like
    flow:free on container + use of top/left props in children.

Having this you will be able to define active and accessible
scene as:

<div #accessible-fish-tank>
   <ul><li class="fish guppy" href="..">Marina</li>
          <li class="fish catfish" href="..">Ivan</li>
          <li class="fish pike" href="..">Olga</li></ul>
   <button type=checkbox>Freeze</button>
</div>


In my implementation of Graphics in Sciter
you can get Graphics in script from any DOM element.
Generated Graphics layer is drawn on top of background layer but
before or instead of content layer of the element.

I am not using dedicated <canvas> element at all.

That allows you to have semantically meaningful
and accessible markup/DOM with arbitrary complex graphics in it.


-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Sunday, 17 July 2011 16:30:08 UTC