[whatwg] CSS canvas() function
Olli.Pettay at helsinki.fi
Wed Dec 1 15:45:51 PST 2010
On 12/02/2010 01:43 AM, Tab Atkins Jr. wrote:
> On Wed, Dec 1, 2010 at 3:38 PM, Olli Pettay<Olli.Pettay at helsinki.fi> wrote:
>> On 12/02/2010 12:42 AM, Tab Atkins Jr. wrote:
>>> On Wed, Dec 1, 2010 at 2:16 PM, Tab Atkins Jr.<jackalmage at gmail.com>
>>>> 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:
> var frame = document.createElement("iframe");
> frame.src = "http://www.example.com"
> document.cssElementMap.foo = frame;
> 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.
More information about the whatwg