To account for spacing between bases or text boxes during reflow, the line
layout which manages the bases updates its inline direction coordinate based on
the preferred inline size for the corresponding text boxes. Next, the base is
reflowed at the correct inline coordinate. Each paired text box is then also
reflowed at the proper inline position determined by (1) the current position of
its corresponding base and (2) its own preferred width.
In computing intrinsic widths, accounting for spacing is less complicated. The
minimum intrinsic width is the width of the widest ruby column, and the
preferred intrinsic width is the sum of all the ruby column widths. Each ruby
column width is the maximum width of its base box and text boxes. These
individual widths are determined using GetPrefISize on the base and text boxes.
Ruby base container frames store a list of pointers to the ruby text container
frames in the segment they denote. This list of pointers is created in the ruby
frame reflow method before calling the reflow method for the ruby base
container. The list exists and is used only during reflow of the main ruby frame
and is cleared before returning from reflow.
This fixes the positioning of underlines set on a block or its ancestor
when drawn on children of a block that have a vertical-align !=
baseline.
The lazy computation is done all at once for all children of a block to
avoid O(N^2) searches for the line containing a frame.
This fixes the positioning of underlines set on a block or its ancestor
when drawn on children of a block that have a vertical-align !=
baseline.
The lazy computation is done all at once for all children of a block to
avoid O(N^2) searches for the line containing a frame.
This should be backed out for two reasons:
(1) It caused a serious regression with bullets from list-style-image,
which no longer affect the line box height and thus overlap.
(2) The dependency on 'line-height: normal' doesn't make sense; there's
no reason for whether line-height is 'normal' or not to affect the
behavior of bullets.
I don't currently have time to figure out why Gecko behavior differs
from other browsers on bug 942017, but that should be re-analyzed and
the bug fixed in a different way. At first glance, the code should
already be leading to the expected behavior, since the bullet ought to
have the same metrics and alignment as the block's influence on the line
box's height. Why this isn't the case should be investigated.
Prior to this patch, we failed to honor:
* margin-left on elements in inline layout with 0 width and 0 height
* margin-right on elements in inline layout with 0 width
I think that was because the code in CanPlaceFrame to discard both
margins when the width was 0 was running after the left-margin was
applied, unless the later code in PlaceFrame (checking both width 0 and
height 0) un-applied that left margin.
The assertion count change in test_value_computation.html is due to 2
additional "bad width" assertions (I presume from honoring large
margins that were previously ignored).
The change to 538935-1-ref.html is to match an improvement in rendering
of the margins in the test, where both sides of the margin are now
honored.
The change to layout/reftests/text-overflow/marker-basic-ref.html is to
keep the reference (which uses margins) rendering the same way following
the changes to margin handling.
The new behavior (in the reftests added in layout/reftests/inline/)
matches at least Chromium; I didn't check any other browsers.
