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

Jonas Sicking wrote:
> 
>> 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
> 

That is known as "client side include"

<include src="data.partial.htm">
   Ooops, "data.partial.htm" is not available
</include>

After loading data.partial.htm node of <include> is getting replaced by 
the content of data.partial.htm.

Simple and straightforward.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 30 May 2008 02:41:07 UTC