RE: Canvas as input vs. img (was Using @aria-describedby for long described image links [Was: Using an image map for long described image links [Was: Revert Request]])

I am going to have  to agree to disagree as that is not fully indicative of
how canvas is being used by industry today.


Rich Schwerdtfeger



From: Frank Olivier <Frank.Olivier@microsoft.com>
To: "'Charles Pritchard'" <chuck@jumis.com>, Leonard Rosenthol
            <lrosenth@adobe.com>,
Cc: Maciej Stachowiak <mjs@apple.com>, Steve Faulkner
            <faulkner.steve@gmail.com>, Benjamin Hawkes-Lewis
            <bhawkeslewis@googlemail.com>, John Foliot <john@foliot.ca>,
            Matthew Turvey <mcturvey@gmail.com>, Leif Halvard Silli
            <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer
            <silviapfeiffer1@gmail.com>, Laura Carlson
            <laura.lee.carlson@gmail.com>, Sam Ruby
            <rubys@intertwingly.net>, Paul Cotton
            <Paul.Cotton@microsoft.com>, HTML WG <public-html@w3.org>
Date: 02/08/2012 02:13 PM
Subject: RE: Canvas as input vs. img (was Using @aria-describedby for
            long   described image links [Was: Using  an image map for long
            described image   links [Was: Revert Request]])



IMO all canvas usage can be categorized as

0 - Decorative use - no actual information is communicated
(Example:
http://ie.microsoft.com/testdrive/Performance/ParticleAcceleration/ )

1 - Non-interactive canvas - 'read-only' information
(Example: Drawing a scatterplot + associated labels in canvas; this has
always been possible via server-side generated <img>.)

2 - Interactive canvas - 'user interfaces'
2a Simple single controls - a single checkbox, button, etc (a single
<input> element in the canvas sub-tree)
2b Sometimes more complex things like spline editors (iow multiple <input>
elements/tab stops/focusable areas in the sub-tree)

So, canvas 'is' (plays the same role as) either <img> or non-text <input>
elements.

IMO the major spec work to make 1 and 2a accessible is done; we need a
solution like http://www.w3.org/wiki/Canvas_hit_testing for 2b.

Thanks
Frank


-----Original Message-----
From: Charles Pritchard [mailto:chuck@jumis.com]
Sent: Tuesday, February 07, 2012 1:40 PM
To: Leonard Rosenthol
Cc: Maciej Stachowiak; Steve Faulkner; Benjamin Hawkes-Lewis; John Foliot;
Matthew Turvey; Leif Halvard Silli; Silvia Pfeiffer; Laura Carlson; Sam
Ruby; Paul Cotton; HTML WG
Subject: Re: Canvas as input vs. img (was Using @aria-describedby for long
described image links [Was: Using an image map for long described image
links [Was: Revert Request]])

SVG-based image editors are written in flash. ;-)

It's not any different than an SVG based button. Yes, we're just trying to
get vendors on board, supporting DOM in places they didn't.

My comment relating to the way that HTML Canvas Element was traditionally
implemented.
It's typical for a Canvas implementations to be treated as a simple
element, just an image with a dynamic backing.

I didn't realize the Canvas sub-tree was useful when I wrote my
implementations. Now that we've all figured that out... Once we allow that
sub-elements can receive focus, the Canvas implementations are updated to
use some of the same semantics as form controls, internally.
They have flow, they may have focusable elements that are not visible on
screen. They become a render block, or a frame, instead of being a simple
element with no children.

With SVG, I am more often using <button><svg /></button>, with Canvas, I'm
more often using <canvas><button /></canvas>.
Small distinction, not very important.

-Charles

On 2/7/2012 1:22 PM, Leonard Rosenthol wrote:
> How is this different than the various SVG-based image editors (etc.)
> that have existed for years?  SVG elements, as well as the Canvas
> element (and
> static<img>) all live in the DOM can be interacted with.
>
> Input, to me at least, means not so much that the user can interact
> BUT that the values from input will be read/submitted.
>
> Leonard
>
> On 2/7/12 4:09 PM, "Charles Pritchard"<chuck@jumis.com>  wrote:
>
>> Canvas is widely used for interactivity. The basic example in the
>> HTML5 specs is a checkbox example.
>>
>>
>> The majority of Canvas uses are for UI, not simply for procedurally
>> generated images.
>> While you can generate some interesting images via script, a static
>> PNG file makes more sense in distribution.
>>
>> I found that one out with an extension to a drawing application. I'm
>> sure people in Adobe have seen this as well with things like
illustrator.
>>
>> I was so happy that we were capturing all of the information needed
>> to redraw an image. Then, I noticed that it took longer to redraw the
>> image than it did to download a copy that had already been rendered.
>>
>> The name of this site is a little silly, but it gives a nice view of
>> how programmers are using JavaScript in experimentation:
>> http://badassjs.com/

>>
>> Notice, the Js1k demos are just programmatic images. Those are demos
>> though, intentionally tricky and small.
>>
>> For actual apps, you have something like "Morning Star: An Impressive
>> Audio Synth in JavaScript".
>> http://badassjs.com/post/16764713909/morning-star-an-impressive-audio

>> -synt
>> h-in-javascript
>>
>>
>> -Charles
>>
>> On 2/7/2012 12:54 PM, Leonard Rosenthol wrote:
>>> This is interestingŠ
>>>
>>> What makes you think that Canvas is (or should be) anything more
>>> than a programmatically described image?
>>>
>>> Leonard
>>>
>>> On 2/7/12 3:40 PM, "Charles Pritchard"<chuck@jumis.com>   wrote:
>>>
>>>> The issue with Canvas is that implementers did not realize that
>>>> Canvas is in some abstract sense, a form element.
>>>> "the best way to fix it is to make [it] more like a form control"
>>>> https://bugs.webkit.org/show_bug.cgi?id=50126

>>>>
>>>> In all implementations, fixing Canvas seems to be about changing
>>>> the object it inherits from.
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=495912

>>>>
>>>> Canvas is not<img>, it's<input>.
>>>>
>>