I thought I'd file a bug to get this rolling. attinasi and karnaze had (what I thought was) a great idea for dealing with block-in-inline situations ({ib}). Rather than dealing with it at frame construction time (which has proven to be beyond horrible), perhaps we can deal with {ib} as a presentational issue during reflow. Specifically, it ought to be possible to detect the {ib} at frame construction, and simply change the block's display type from `block' to `-moz-compat-inline-block' or something. Then, during reflow, line layout could detect this, force a line break, and place the block on the next line in a block (or block-like) linebox. At first blush, it seems like we'll probably need to create a third type of linebox for {ib}'s, so that we can a) still maintain the block-like behavior (including margin collapsing and such), but also b) deal with the inline continuation frames that will necessarily be created around the {ib}.

So I started playing with something similar to this idea a few weeks ago, to see whether it would be easy, and what problems I might run into. I ended up running into some problems. But I do have a patch to share that might be useful as a start. The main problems with this patch are: * It doesn't work. Horribly. Meaning, {ib} stuff just doesn't show up anymore. * There are a bunch of bits with some sort of "XXX not written yet" that are unrelated to the fact that it doesn't work. * Frames aren't parented to the block, so we'd need to do a good bit of coordinate hacking to set the right coordinates during block reflow. (Perhaps we could use something like placeholders and NS_FRAME_OUT_OF_FLOW, but that basically puts us back where we started.) * The HAS_CHILD_WITH_VIEW and similar frame state bits aren't going to make much sense. We'll end up propogating them to the inline. We'd need to figure out how we wanted to handle painting and event targetting -- whether from the inline or from the block. It might be true that either would work, but I suspect we'd need to do it from the block, which is a bit more work. * There would be a bunch of other similar problems that I haven't even thought of yet since the patch hasn't had any testing yet.

Changing QA Contact

-> kin

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

do we have any data on perf enhancement gains?

This isn't about performance enhancement (although it might help). It's about changing a design that's a constant source of bugs and that is sucking up large amounts of engineering time, as well as being thousands of lines of code that we don't need (and one that could expand to thousands more before we get the bugs out of it).

But while debugging in the past, I have seen more than a few pages that reframe multiple times while loading. I don't recall bug numbers or pages in particular, but for those pages, this would be a significant performance gain.

kin: are you actively working on this? If not, I might be interested in taking it.

I pinged dbaron last week via AIM regarding this, but I figured I might as well say it here too. I'm not actively working on this, since I'm currently distracted by some stuff for an internal Netscape project. When I was experimenting with this, I was playing with the approach of using the splitting mechanism to get everything on the correct lines, which was a bit different from dbaron's approach of leaving the frame hierarchy "untouched" as he described on IRC a few months back. I think I left off trying to figure out a clean way to get child blocks of inline frames to reflow using the parent block's state so that the child blocks could flow around floaters. I guess I was thinking that if we left the hierarchy untouched we would have to do a significant rewrite of linebox and the way it reflowed it's contents. If I remember correctly, and keep in mind this was a while ago, I think I was concerned about cases like this where we had blocks in nested inlines. <font>text1<br><font>text2<div>DivText</div>text3</font>text4</font> Maybe I took dbaron's "untouched" comment a bit too literally and he may have been planning to include some level of splitting anyways?