This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This is the first patch of bug 1684236 tweaked as per review comments.
Keeps us with one source of truth for reflowInput.
This could be cleaned up in the future if we manage to remove that
printing hack or what not.
Co-Authored-By: fantasai <fantasai.cvs@inkedblade.net>
Differential Revision: https://phabricator.services.mozilla.com/D181857
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
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
When balancing columns, if a block frame doesn't have enough available
block-size for a float's continuation, we move the float continuation into the
block's pushed floats list.
Typically, the float's continuation is expected to be pulled by the block's next
continuation and reflow there. However, if the block happens to be in the *last*
column, the float continuation will stay in the pushed float list until we
reflow its block again in the next column balancing loop. In this case, we
should pull it from the pushed floats list regardless of whether the
continuation has a previous continuation or not. Otherwise, it will not be
reflowed if it remains in the pushed floats list.
Differential Revision: https://phabricator.services.mozilla.com/D178141
This patch shouldn't change the behavior.
- Use `nsIFrame::PresShell()` to get PresShell directly.
- Rewrite the loop, and rename `next` to `prevSibling` for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D178140
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
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
The only functional change in this patch is the added `else` clause.
Other changes are non-functional such as removing the `Note` and retrieving
block-end BP directly from `borderPadding` (an alias of
`BlockReflowState::BorderPadding()`). We can simplify it because nowadays
`BlockReflowState::BorderPadding()` won't skip the block-end border and padding,
and `mBorderPadding` is initialized with `PreReflowBlockLevelLogicalSkipSides()`
[1], which always assumes the current fragment is the last fragment.
The only difference between the added test and reference file are `height` and
`max-height`, so the test verifies the fragmentation are consistent internally.
[1] https://searchfox.org/mozilla-central/rev/4a5c56f4aca291802ce27320cd9a752dd5dd955e/layout/generic/BlockReflowState.cpp#43-46
Differential Revision: https://phabricator.services.mozilla.com/D176614
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
Prevents backplates from being drawn for any text that has forced-color-adjust: none set by checking the value of StyleText()->mForcedColorAdjust.
Differential Revision: https://phabricator.services.mozilla.com/D173362
