DescriptionBehave more normally for content taller than the fragmentainer it's in.
Refusing to break just because content happens to be taller than the multicol
container is just weird, and it's getting in the way for fixing bug 439820.
If we had behaved the same way for line layout, we'd refuse to wrap to the next
line if we encountered a word that was wider than the container (in addition to
being too wide at the current inline position on the line). If the text to lay
out is "abc def ghijklmnopqr stu" and the container has room for 10 characters,
we'd lay out like this:
+----------+
|abc def ghijklmnopqr
|stu |
+----------+
instead of this (the correct way):
+----------+
|abc def |
|ghijklmnopqr
|stu |
+----------+
The usefulness of the hasUniformPageLogicalHeight thing vanished into thin air
in the process (calling pageLogicalHeightForOffset() isn't that expesive).
Having one bit in LayoutFlowThread specifying if column heights are uniform was
just bogus anyway, since column sets are typically separated by column
spanners, and if the heights of the set preceding and following a spanner
differ, why should adjustLinePositionForPagination() care? This was a relic
from the CSS regions days, thought to also be useful for multicol. But it
isn't.
R=dsinclair@chromium.org
BUG=
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=198415
Patch Set 1 #Patch Set 2 : Manually rebaseline fast/repaint/multicol-with-text. Get rid of platform-specific expectations. #Messages
Total messages: 5 (1 generated)
|