- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 8 Feb 2012 12:22:53 -0800
- To: Leonard Rosenthol <lrosenth@adobe.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>
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 UTC