L. David Baron wrote:
> This makes some sense (given that you meant formatting context rather
> than containing block). I made some "XXX" comments somewhere in
> nsBlock*.cpp saying that I had no idea how even the simple cases for
> that type of thing currently work (and I was surprised that they do).
> If my memory is correct, I later found some very messy code that
handles
> those cases (but probably not very well, I expect).
Actually it works OK, and I have code that makes it work OK even in
dynamic contexts. I mean it works OK in the sense of building a
reasonable frame tree. I expect that the wrong containing block
geometry is being used.
> As to getting widths from the containing block (bz's comment) -- we
can
> currently map from float to placeholder; from there it's not hard to
get
> to the block. If needed, we could make it even easier.
Just mapping from the float to its placeholder isn't enough, we have to
find a placeholder that is parented by the "real" containing block.
There's a question related to this that I'm currently thinking about
with my dynamic paginated floats patch. How closely should a float
continuation reflect the geometry of its prev in flow? More generally,
how consistent should widths, x-offsets etc be across breaks?
E.g. if you have a column set containing floats that in galley mode
would look like this (where A is fixed width and B is using shrinkwrap
width)
AAA BBB
AAA BBB
BBB
BBB
BBB
and we break after three lines, should we get
AAA BBB
AAA BBB
BBB
-------------
BBB
BBB
or
AAA BBB
AAA BBB
BBB
-------------
BBBBBB
?
Currently we get the former, but I'm thinking of changing it to the
latter. The latter uses real estate more effectively, is more intuitive
if you can't see the first column/page, and is just as easy to
implement in our code. I just wonder whether something in CSS
constrains the decision.
> However, it seems like it won't actually be much use to make this
change
> if, when we start splitting absolutely positioned elements for
printing,
> we have to do the same thing (that we're now doing for floats). An
> absolutely positioned element could be a child of a small relatively
> positioned block. The block could stay on one page, and the abs pos
> element could need to be split onto the next. This has the same
problem
> of how to parent the continuation.
Hmm. I guess we'd need to push it up to the nearest absolute containing
block, or something like that. So I guess we'd be stuck with a hack
like we currently have.
Rob
_______________________________________________
mozilla-layout mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-layout
