Re: [css3-values][css3-images] element() function

On Wed, Sep 1, 2010 at 4:58 PM, Simon Fraser <smfr@me.com> wrote:

> 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); }
>

element() has its own namespace of identifiers, just like -webkit-canvas
does, but it happens to fall back to the ID-namespace when no identifier has
been set by setImageElement. Maybe removing the # would help make this
clearer.

Maybe a better alternative would be some CSS OM API that allows you to set
> background-image to a reference to some element.
>

That forces you to use more script.

We should also think about this in terms of how we might wish to reference
> elements in the page for a future filter property.
>

Yes, I'd like to be able to use element() there too. And for mask,
clip-path, fill, stroke, text-path, etc.

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.
>

I guess something could be worked out, but it seems tricky. If you render a
<span style="display:none">, what kind of CSS box do you create to render
it?

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.
>

Yes, I'm sure we can come up with something better.


> 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>?
>

Not at the moment. That could be added though.

If so, are there security implications?
>

No. element() creates no new ways to access pixel data.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]