Handling floats in a block that's not their immediate ancestor
Boris Zbarsky
start doing blocks-of-blocks-or-inlines, I think it might be good to
have the block-of-blocks be the float containing block for all the
floats whose nearest block is a block-of-inlines for the
block-of-blocks... Could we conceivably get that working in
nsBlockFrame before we try splitting classes? It'd simplify frame
construction a good bit (e.g. no need to reparent floats when splitting
a block-of-inlines in two because a block was inserted between two inlines).
-Boris
Robert O'Callahan
> Right now floats use the nearest block as their containing block. If we
> start doing blocks-of-blocks-or-inlines, I think it might be good to
> have the block-of-blocks be the float containing block for all the
> floats whose nearest block is a block-of-inlines for the
> block-of-blocks... Could we conceivably get that working in nsBlockFrame
> before we try splitting classes?
What exactly do you mean by "get that working" in the current world?
Currently the float containing block is just the nearest block parent of
the placeholder ... what would you change?
Rob
L. David Baron
I think the float's containing block is actually used for layout
calculations in some ways. I wonder if it might be better for the
float containing block to always be the block of inlines (which I
think would happen automatically if we did the split); I think it's
possible that might actually fix some existing bugs.
But my memory is a little rusty. It might be worth looking into,
though.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Boris Zbarsky
If we go to blocks-of-inlines and blocks-of-blocks there are two
questions (which I sadly conflated in my original mail; that's what I
get for mailing at night):
1) What is the CSS containing block for the float (e.g. what should be
used as the basis for percentage sizes)? Per CSS spec, this is
ambiguous given Bert's claims that "box" in section 10.1 actually means
"element". If one assumes it really means box, then the containing
block seems like it should be the block-of-inlines. Which answer is
correct?
I just tested, and Webkit uses the block-of-inlines. Everyone else
(Opera 10, IE8, us) uses the block-of-blocks or equivalent. I've posted
to www-style about this disagreement.
2) If the block-of-blocks is the containing block (which I think it
should be), then what should the parent frame of the floats be? If the
containing block is the block-of-inlines then floats should
unambiguously be parented to it, I think.
Having the floats be kids of the block-of-blocks would be somewhat
simpler from a frame construction perspective, since then inserting a
block between two inlines would only need to split its parent
block-of-inlines in two and reparent the inlines without having to worry
about float reparenting, right? On the other hand if floats are tied to
line boxes, maybe that's difficult...
So the "changing" wouldn't be quite in the current world, but in the
world where frame construction has been changed (or is about to be
changed) to do blocks-of-inlines and we haven't split up the two block
classes yet. If floats are parented to the block-of-blocks, then its
reflow will need to reflow them correctly; I believe right now blocks
rely on float placeholders being found on one of their inline lines, right?
-Boris
Boris Zbarsky
> I think the float's containing block is actually used for layout
> calculations in some ways.
See my reply to roc. Are you talking about the CSS containing block
here, or the parent frame in our frame tree? I realize they match right
now; but in the future we _could_ have the latter be the
block-of-inlines while the former is the block-of-blocks...
> I wonder if it might be better for the
> float containing block to always be the block of inlines (which I
> think would happen automatically if we did the split)
Without changes to blockframe or reflow, yes. Would need some frame
constructor surgery on dynamic changes (or adding more
WipeContainingBlock ickiness). This would make us match Webkit's
behavior, but not our own right now or Opera or IE8 (if we're talking
about the CSS containing block).
-Boris
Boris Zbarsky
> If we go to blocks-of-inlines and blocks-of-blocks there are two
> questions
And actually a third question, unrelated to floats: should there be
non-anonymous blocks of inlines? The argument for "yes" is that if a
block only has inline kids we can then avoid creating an extra anonymous
frame. The argument for "no" is that if such a block then has a block
kid added we have to reframe or something. I'm coming to think that
anything that causes us to reframe in common cases web content will hit
(esp. parsing, which would be the case here) is a performance minefield
just waiting for a web page that we load in 10-100x the time other
browsers need....
-Boris