- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Wed, 8 Feb 2012 13:13:18 -0800
- 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>
- Message-ID: <CABNRm603QBwaD9pdRtCdHRhQdZ9Fu0OdTpaw7FYATNz2MGah6w@mail.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 UTC