- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 10 Feb 2012 18:10:06 -0800
- To: Ryosuke Niwa <rniwa@webkit.org>
- 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: <4F35CDFE.8090204@jumis.com>
Yes, I've been active on component model threads, and I am cautiously monitoring the development of Web Components, hoping to avoid some of the a11y issues we hit in Canvas. I've remarked a few times that this model, with Canvas, is a component model. There's some semantic ambiguity when we start talking about Canvas and the Component model. Example: Shadow DOM. Early on, the Canvas subtree was referred to the shadow DOM. I will be experimenting with the experimental Shadow DOM in Webkit, in conjunction with Canvas. I suspect that there will be several issues that come up again, in terms of exposing ARIA information through to the OS. There may be similar issues with the CSS generated content model. <div style="content: url(img.png)"><button /></div> I don't see people using that method, but it is something to be aware of. Another cross-over/issue I've been examining is toggling visibility of fallback content via css: such as in: <div is="x-custom-element">fallback content</div> and <canvas>fallback content</canvas>. My theory is that <canvas> is, inadvertently, the first visual web components model to be picked up by all vendors. ARIA is the first non-visual web components model. We're using lessons from those to follow work on Web Components to ensure it's done in a way that works for all users and authors. -Charles On 2/8/2012 1:13 PM, Ryosuke Niwa wrote: > > 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 > <mailto: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 > <mailto: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 > <mailto: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 Saturday, 11 February 2012 02:10:36 UTC