[whatwg] CSS canvas() function

Tue Nov 23 17:23:08 PST 2010

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