[whatwg] CSS canvas() function

Tab Atkins Jr. jackalmage at gmail.com
Wed Dec 1 15:43:04 PST 2010

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


More information about the whatwg mailing list