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