On 12/02/2010 01:43 AM, Tab Atkins Jr. wrote:
On Wed, Dec 1, 2010 at 3:38 PM, Olli Pettay<[email protected]>  wrote:
On 12/02/2010 12:42 AM, Tab Atkins Jr. wrote:
On Wed, Dec 1, 2010 at 2:16 PM, Tab Atkins Jr.<[email protected]>
  wrote:

I've gone with using element() for selectors (limited to only ID
selectors, but other valid selectors are accepted, they just don't
currently do anything).  Then element-ref() takes an ident, which the
js function maps to an element.

So, this said, there are few relevant details to work out.
mozSetImageElement allows you to associate elements not in the
document.  This is obviously a problem in general, since
out-of-document elements aren't rendered, and you need a surprising
amount of information to correctly render an element in such a way.

I believe that right now, Moz just ignores any out-of-document element
that's not an<img>,<canvas>, or<video>, right?  Basically, anything
that has some intrinsic notion of what it should look like.  This
seems reasonable to me.

What about other elements that don't necessarily care about their
surrounding elements, like<object>s or<iframe>s?

Did you read http://hacks.mozilla.org/2010/08/mozelement/ ?
It has an example for iframes.

My question was specifically for an out-of-document<iframe>.
In-document, all elements are obviously valid.

Something like:
<script>
var frame = document.createElement("iframe");
frame.src = "http://www.example.com";
document.cssElementMap.foo = frame;
</script>

Should this work?  The rendering of a non-seamless<iframe>  doesn't
depend on any other elements in the document.  In general, any
replaced element seems to fall into this camp.

Ah, different case.
Gecko doesn't load iframes which aren't in document.

-Olli



~TJ


Reply via email to