On Aug 31, 2010, at 9:37 pm, Robert O'Callahan wrote:
> On Wed, Sep 1, 2010 at 5:57 AM, Simon Fraser <smfr@me.com> wrote:
> Agreed, I think -webkit-canvas is a different beast to element(). -webkit-canvas simply creates a canvas context with the specified height and width; there is no associated canvas element, and there's nothing in the document.
>
> You can get very close to -webkit-canvas using element() with the setImageElement API. In particular, a referenced canvas need not be in the document. E.g.
>
> var e = document.createElement("canvas");
> var ctx = e.getContext("2d"); drawInto(ctx);
> window.setImageElement("anon-canvas", e);
>
> .canvas-background { background:element(#anon-canvas); }
I find window.setImageElement() one of the weirder parts of the spec. It seems bad to allow the user to do something like:
<div id="first">...</div>
<div id="second">...</div>
window.setImageElement("first", document.getElementById("second"));
.foopy { background:element(#first); }
Maybe a better alternative would be some CSS OM API that allows you to set background-image to a reference to some element.
We should also think about this in terms of how we might wish to reference elements in the page for a future filter property.
>
> One useful use case I see missing with element() is the ability to reference an element in a display: none subtree, so you can, for example, have some nodes in the <head> that you use to draw HTML content into a <canvas> or CSS background or WebGL.
>
> Arbitrary display:none HTML content doesn't have CSS boxes so I'm not sure how you would want it to be rendered.
You'd create CSS boxes for the purpose of rendering the CSS image. The boxes would not be hooked up to the visible box tree of the page. There is the question of how you lay out a disconnected subtree like this (e.g. if the root box has a percentage width), but maybe you just pick an arbitrary size if the style does not specify an absolute size. Or maybe you just behave as if it were a child of the initial containing block.
This is actually the use case we think is more common than using an element which is already visible on the page. The height:0; overflow: hidden approach seems like a unfortunate hack to get the same behavior.
> element() is able to render <canvas>, <video> and <img> elements that are display:none or not in the document. That list could be extended to any other type of element that has its own "natural" non-CSS rendering. Perhaps <svg> could be added to that list.
That makes sense. Does that list include <iframe>? If so, are there security implications?
Simon