Re: correct and incorrect uses of canvas

On 7/17/2011 9:29 AM, Andrew Fedoniouk wrote:
>> -----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.
That's the kind of markup I'd suggest using in both SVG and Canvas if 
it's appropriate;
SVG using foreignObject, canvas using the shadow dom.

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

This part of the authoring tool is something that many vendors are 
taking very seriously.
http://www.w3.org/TR/ATAG10/

I've not worked with Inkscape for awhile, it's certainly an amazing tool,
and as I get back into SVG-mode, I'll interact with that community more 
often.

It's certainly been mentioned in developer discussion:
http://wiki.inkscape.org/wiki/index.php/SVG_Tiny_Compliance
https://bugs.launchpad.net/inkscape/+bug/170340

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

No, that would not help anyone. But it would help to have a fuller 
description than simply "flower".
And if the image were interactive, that is, if one could click on some 
of the larger flowers, it'd
make sense to have those marked up as such. The top and bottom of the 
stem could be marked up
to some minor use.

In SVG you can provide -more- semantic data than with an HTML img. HTML 
img did have
the longdesc attribute, but that's been pushed out of HTML5, I believe.


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

Perhaps you're speaking to "automatic" A11y foundations. I don't believe 
automatic
descriptions match the quality of human generated descriptions ("human 
language").

Both Canvas and SVG support HTML5, Canvas in the immediate sub-dom (a 
much closer relationship),
and SVG within <foreignObject> tags. I'd like to see the SVG situation 
improved; I don't see the issue with
Canvas as it supports HTML5+ARIA.


> The solution (for the Graphics) is
> 1. to allow client side image generation using Graphics.
I don't understand this.
> 2. to allow use of such images as backgrounds in CSS so for any element.
CSS backgrounds are hidden by the client in High Contrast modes. That said,
Canvas is enabled in Mozilla and WebKit to use as a css background. As 
is SVG (I believe).

> 3. to provide lightweight positioning mechanism like
>    flow:free on container + use of top/left props in children.
There is a wrap-image and wrap-shape proposal for CSS3 on the table.
There is also a pointer-events: opacity(n) proposal. I'm advocating for 
them.

They're certainly helpful.

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

So does simply embedding that data in a canvas element:

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

More often, canvas authors are going to use a limited set of elements;
things work out easier that way. Applying a background image on every
dom object would require more work on the author, and more ram.

It's not a -bad- solution, but it's not the only solution. It's just an 
option.

Nothing is lost in the canvas example; it more closely matches how authors
currently use canvas, and it allows more flexibility in performance.

That said, your example closely resembles something we might do
to support legacy clients running on FF 3.x, adjacent to the canvas DOM,
as transparent and absolutely positioned elements.

-Charles

Received on Sunday, 17 July 2011 19:01:19 UTC