W3C home > Mailing lists > Public > public-html@w3.org > February 2012

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]])

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 8 Feb 2012 12:22:53 -0800
Message-Id: <25A5E8EC-5448-47AA-9BAB-A4390C3317E8@jumis.com>
Cc: "Frank.olivier@microsoft.com" <Frank.olivier@microsoft.com>, 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>
To: Leonard Rosenthol <lrosenth@adobe.com>
Yes, when the DOM is supported for Canvas, it's no different than SVG "input". State information is exposed and consumed through the DOM.


-Charles



On Feb 8, 2012, at 7:00 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote:

> I think your #2 goes towards Charles' parentage of the canvas vs. button
> as described below.
> 
> If you inverted the parentage of canvas vs. button below, so that the
> canvas is a child of button, then it would simply serve as the
> "appearance" of the button - which is what you want for #2a below and does
> NOT NEED to imbue canvas with any input role.
> 
> 2b, however, is definitely more interesting as it does imbue input
> characteristics to canvas - but it's something that can't (AFAIK) be
> submitted as part of a form.  But it's no different in terms of "input"
> than DOM modification for SVG elements, at least once the hit testing
> problem is resolved.  And perhaps that resolves the need for it then have
> "input" characteristics.
> 
> Leonard
> 
> 
> On 2/7/12 7:32 PM, "Frank.olivier@microsoft.com"
> <Frank.Olivier@microsoft.com> wrote:
> 
>> 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>.
>>>>>> 
>>>> 
>> 
>> 
>> 
>> 
> 
> 
Received on Wednesday, 8 February 2012 20:23:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:43 GMT