Re: [whatwg] The <iframe> element and sandboxing ideas

> On Mon, 23 Apr 2007, Jonas Sicking wrote:
>> There's a big difference to that and to what I'm proposing. With what's 
>> in bug 80713 you're still limited to a box that basically doesn't take 
>> part of the outer page at all. For example in the table example in my 
>> original post the headers of the table would not resize to fit the 
>> column sizes in the <include>ed table.
> 
> Woah. That's far more radical. I have no idea how to do that. How would 
> you make the parser not generate the implied elements and switch straight 
> to the "in table" mode? How would you make the CSS model work with this? 
> How would you define conformance for the document fragments?

The parser questions here are interesting for sure, but I believe they 
could be solved.

One way to solve the "don't make the parser switch into mode X when it 
hits the iframe" would be to teach the parser about <include> (or 
<iframe seamless>, or <iframe include>, or whatever it'll be called). 
That is pretty ugly though.

One way to solve the fragment issue would be to say that the inner 
document always has to be a full document, and then use a fragment 
identifier to point to the contents of a table.

The CSS model is simpler. XBL deals with exactly the same problem of 
combining multiple DOMs into a single flattened tree on which CSS is 
applied.

I'm still intending to do some testing with this idea once I get more 
time. A lot of the implementation details have to be solved for XBL anyway.

/ Jonas

Received on Wednesday, 28 May 2008 22:26:22 UTC