- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 28 May 2008 15:23:28 -0700
> 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 15:23:28 UTC