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
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.
That is known as "client side include"
Ooops, "data.partial.htm" is not available
After loading data.partial.htm node of <include> is getting replaced by
the content of data.partial.htm.
Simple and straightforward.