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: Ryosuke Niwa <rniwa@webkit.org>
Date: Wed, 8 Feb 2012 13:13:18 -0800
Message-ID: <CABNRm603QBwaD9pdRtCdHRhQdZ9Fu0OdTpaw7FYATNz2MGah6w@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: John Foliot <john@foliot.ca>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Matthew Turvey <mcturvey@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, HTML WG <public-html@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Laura Carlson <laura.lee.carlson@gmail.com>, Steve Faulkner <faulkner.steve@gmail.com>
That sounds like the Web component model. I don't think we let the original
DOM recieve the focus, etc... but it's probably worth thinking about this
problem in the conjunction with the component model.

- Ryosuke
On Feb 7, 2012 1:43 PM, "Charles Pritchard" <chuck@jumis.com> wrote:

> 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<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<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<https://bugzilla.mozilla.org/show_bug.cgi?id=495912>
>>>>>
>>>>> Canvas is not<img>, it's<input>.
>>>>>
>>>>>
>>>
>
>
Received on Wednesday, 8 February 2012 21:13:49 GMT

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