[whatwg] The <iframe> element and sandboxing ideas
jonas at sicking.cc
Wed May 28 15:23:28 PDT 2008
> 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
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.
More information about the whatwg