Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
SetFrame() is equivalent to `operator=`, so external callers can use `operator=`
instead. For the two callers wanting to set `nsFrameList` to `AbsoluteFrameList`
in `nsCSSFrameConstructor`, removing SetFrame() disallows it. However, we can
easily change the declaration from `nsFrameList` to a `AbsoluteFrameList` to
resolve the problem.
Differential Revision: https://phabricator.services.mozilla.com/D160840
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Bug 1674302 made table flex item to be able to grow or shrink towards
another size. However, for an inflexible table flex item, its
hypothetical main size is the final main size. We have to compute the
flex base size correctly when generating FlexItem.
With Part 1, it's easy to change nsTableWrapperFrame::ComputeSize() to
return the correct block-size.
Differential Revision: https://phabricator.services.mozilla.com/D106156
We already compute both the inner table frame and the caption frame's
block-sizes in InnerTableShrinkWrapSize() and CaptionShrinkWrapSize(),
respectively. Rather than throwing them away, popping them up to
ComputeAutoSize().
This is a preparation patch for Part 2, and it hasn't changed the
behavior yet.
Differential Revision: https://phabricator.services.mozilla.com/D106155
This is the main patch of this bug.
When a flex container provides size overrides for a table flex item,
there are two use cases.
(1) When resolving flex base size, we want to use `flex-basis` to
replace the preferred main size on the *inner table frame* directly.
This is how `height` works on a table element. That is, it sets the
height of the inner table frame, not the table wrapper. This patch
invents `mApplyOverridesVerbatim` flag to tell table wrapper frame don't
do any modification.
(2) When overriding main-size/cross-size for a table flex item, the size
is for *table wrapper frame*. To apply the size to inner table frame,
the table wrapper frame needs adjust the size by subtracting the area
occupied by caption, border, and padding (depending on the box-sizing).
This patch fixes the flex base resolution, and implements the logic for
(2).
We use nsLayoutUtils::GetStyleFrame() to dig into inner table's sizing
properties when resolving flex base size, so we can stop inheriting flex
properties to table wrapper frame in ua.css.
We also need to check style frame's StylePosition() in IsCrossSizeAuto()
so that non-'auto' sizes can prevent tables from being stretched in the
cross axis, just as happens with other flex items. Otherwise with this
patch, the table flex item with fixed height in
dom/flex/test/chrome/test_flex_item_rect.html will be wrongly stretched.
Differential Revision: https://phabricator.services.mozilla.com/D103437
This is a preparation patch for bug 1674302. We'll need border padding
to reduce the size for inner table size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D104643
If the table wrapper frame has a caption, several sizes that are used to
initialized inner table's ReflowInput needs to be reduced:
1. the available block-size,
2. containing block size,
3. StyleSizeOverrides (will be considered in bug 1674302).
This patch gives CreateReflowInputForInnerTable() an argument to pass
the space occupied by the caption in order to reduce the above sizes.
Note the old code doesn't reduce the constrained available block-size
when recreating ReflowInput for a table grid item, but this patch does.
Also, this patch goes ahead to recreate ReflowInput when the area
occupied by caption is non-empty, which may or may not affect the
containing block size for grid item. But for now, I keep it simple
because bug 16743202 is going to add logic that needs to recreate
ReflowInput when there is any size overrides. I tend not to
over-optimize the performance.
Differential Revision: https://phabricator.services.mozilla.com/D104642
Grid container stores the containing block size on a table wrapper grid
item in GridItemCBSizeProperty(), but the size is also passed as a
parameter when creating table wrapper's ReflowInput, and is stored in
ReflowInput::mContainingBlockSize. We can use mContainingBlockSize
directly instead of GridItemCBSizeProperty().
The test 002.html is inspired from the testcases in bug 1527734.
003.html and 004.html are inspired from the testcase in bug 1521088.
004.html is 003.html with 'width:500px' added to <table>, which we still
fail with this patch.
Differential Revision: https://phabricator.services.mozilla.com/D104144
When creating a ReflowInput for inner table frame in
CreateReflowInputForInnerTable(), we pass the customize border & padding
if the table frame is border-collapsed.
Similarly, when creating a SizeComputationInput for inner table frame,
we should be able to pass border & padding rather than having a
specialized logic in SizeComputationInput::InitOffsets(). This patch
makes this a reality.
Differential Revision: https://phabricator.services.mozilla.com/D104350
If the table wrapper frame has a caption, we don't need to compute the
flags twice, because the flag can be determined solely by table wrapper
frame's properties.
Differential Revision: https://phabricator.services.mozilla.com/D104349
Bug 1688690 has ensured inner table's computed margins are all zero.
Here, the only caller is asking the margin of the inner table, which is
always 0. Hence this patch.
Differential Revision: https://phabricator.services.mozilla.com/D104348
Split OuterBeginReflowChild() so that we don't need to branch logic for
caption and inner table.
Rename the methods because OuterBeginReflowChild() only creates the
ReflowInput, and has nothing to do with actual reflow. We could give
both methods the same name like `CreateChildReflowInput` and rely on
function overloading to call the correct method depending on the frame
type, but I prefer clearer method names.
Differential Revision: https://phabricator.services.mozilla.com/D104106
The purpose of InitChildReflowInput() is to provide customized border,
padding, and containing block size for the *inner table frame*, not for
the caption frame. So the caption frame's ReflowInput doesn't need to be
initialized in a separate step.
Differential Revision: https://phabricator.services.mozilla.com/D103436
This patch makes the following changes:
1. Don't call ReflowInput::CalculateBlockSideMargins() for nsTableFrame
so that setting nsTableFrame's computed margins to zero in
SizeComputationInput::InitOffsets() remains true. Also, add an assertion
in nsTableFrame::Reflow() to ensure that.
2. Remove useless nsTableFrameWrapper::GetChildMargin() because the
method is used to get nsTableFrame's margins, which are now all zero.
Also, the old code that subtracts the block-axis margin from available
block-size doesn't really make sense.
3. Pass all-zero innerMargins to nsTableWrapperFrame::SetDesiredSize(),
and use table wrapper's content-box inline-size as the final desired
border-box inline-size rather than reconstructing it from caption and
inner table's inline-size & margin like the old code.
This inline-size already takes inner table's intrinsic size and
caption's inline-size into consideration in
nsTableWrapperFrame::ComputeAutoSize(), and is the final inline-size we
want to use.
In the next part, we are going to simplify all nsTableWrapperFrame's
methods that take inner frame's margin.
Differential Revision: https://phabricator.services.mozilla.com/D103065
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
