- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 23 Nov 2010 17:23:08 -0800
On Tue, Nov 23, 2010 at 4:59 PM, Robert O'Callahan <robert at ocallahan.org> wrote: > On Wed, Nov 24, 2010 at 1:13 PM, Tab Atkins Jr. <jackalmage at gmail.com> > wrote: >> Webkit has for some time now supported using the -webkit-canvas() >> function in CSS anywhere you could use an image >> (<http://webkit.org/blog/176/css-canvas-drawing/>, published in April >> 2008). ?The function takes an ident, which can then be used in the >> window.getCSSCanvasContext() function in javascript to grab a context >> keyed to that ident. ?Drawing on that context is then reflected >> everywhere on the page that references that canvas. >> >> In essence, this is defining a scriptable paint server, which seems >> useful enough that we'd really like it in the platform. > > Out of interest, what use-cases do you have for this? Mozilla people > couldn't think of many that aren't already addressed by other means. The same use-cases addressed below by using setImageElement and a canvas. For example, I've recently been playing with fractals in canvas, and temporarily set my blog to have a screen-filling canvas z-index'd below the content, filled with an interactive fractal (the mandelbrot set, overlaid with the julia set for the point your mouse was over). It would be better/cleaner/easier/more semantic to just draw directly into the <body> background, which is what I was faking with abspos and z-index. >> I'm willing to define a canvas() function in the CSS Image Values >> specification, but since this relies explicitly on an HTML feature, it >> feels like the full definition should exist in the HTML spec. > > One of our goals for element() was to subsume canvas(). Is there a reason to > have an independent canvas() feature if we have element()? > > Note that the setImageElement() API lets you render elements that are not in > a document, so you can get the effect of window.getCSSCanvasContext(type, > id, width, height) with > ? var c = document.createElement("canvas"); > ? c.width = width; c.height = height; > ? window.setImageElement(id, c); > ? return c.getContext(type); > > http://hacks.mozilla.org/2010/08/mozelement/ Ah, right, I'd forgotten about that. I think the *idea* of setImageElement() is great, but the particular implementation is really weird. Why does it override the id? This is CSS, we have other namespaces for a reason. This also interferes with the extension of element() to accept an arbitrary selector, which I'd like to see (it would select the first element that matches the selector). I'd say that we could just let element() take an ident as well and have that refer to a setImageElement()-set value, but that would also interfere with element() taking arbitrary selectors (a tagname selector looks like an ident). How about just using canvas() to refer to setImageElement() things? This retains the flexibility that setImageElement has over getCSSCanvasContext, while removing the weirdness of transparently overriding #ids and keeping element() open to accept arbitrary selectors? (Possibly a different name than canvas(), since you can use setImageElement with any element. The point is just not to step on the toes of element().) ~TJ
Received on Tuesday, 23 November 2010 17:23:08 UTC