This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This was already happening correctly when placing grid items, but it was not
implemented correctly when measuring the overal grid size.
Ideally, MaxSizingFor or some kind of replacement could do this kind of check
already. If you don't want to fiddle around with sizing functions then you
probably want to perform this check every time, and if you really need the
max sizing function directly you can just get it with SizingFor.
Differential Revision: https://phabricator.services.mozilla.com/D220196
It is better to include the level number in the URL (e.g. css-grid-2) since the
chapter number might differ between level 1 and level 2. Note: subgrid is
defined in level 2.
Differential Revision: https://phabricator.services.mozilla.com/D219013
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
This patch doesn't change behavior.
The '-moz-available' keyword is our closest equivalent to the CSS 'stretch'
keyword, *specifically* for the inline axis (since we currently nerf
'-moz-available' to behave like the initial value in the block axis). Hence, it
makes sense to say that the '-moz-available' keyword "Behaves Like Stretch On
Inline Axis".
By abstracting the existing behavior behind this helper-function, we can
start implementing the actual 'stretch' value in terms of this existing
behavior, in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D217685
If an alignment group has no items with a baseline parallel to the
baseline alignment axis, then the fallback alignment is used.
Differential Revision: https://phabricator.services.mozilla.com/D216794
All items in an alignment context should be checked for baseline
alignment. Items that turn out to be orthogonal to the alignment
context should synthesize a baseline.
`grid-self-baseline-horiz-004.html.ini` and
`grid-self-baseline-vertical-rl-003.html.ini` are fixed in the follow
up patch: D216794.
The other errors are due to previously succeeding by chance.
Differential Revision: https://phabricator.services.mozilla.com/D216793
These properties were added as part of the experimental Masonry support added
in bug 1607954. Since then the CSS WG resolved to remove these properties in:
https://github.com/w3c/csswg-drafts/pull/9529
This patch is a fairly brain dead removal of the properties, simply changing
the consumer code to take the code paths that would have been taken previously
if the properties were not set. That leaves some obvious dead code, which has
been removed, but no attempt has been made to redesign the Masonry code to
"make sense" without these properties. That would require a more prolonged
effort to understand Masonry, how the spec has changed in the last four years,
and how we should best change our code.
For now, this removal is simply focused on reducing the amount of memory used
by nsStyleDisplay to unblock the landing of bug 1899949.
Differential Revision: https://phabricator.services.mozilla.com/D212358
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
LogicalAxis is one of the Logical* enums. Converting it from enum to
enum class increases type safety. To run with the pre-existing code,
type casting was added when needed. Comments have been edited where
needed.
Differential Revision: https://phabricator.services.mozilla.com/D206108
Values were static_casted where required. Some functions in WritingModes.h were
rewritten such that bitwise operations aren't being used. Added static_casts to
avoid (debug) build errors from debugging printfs in layout/tables/nsCellMap.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D205510
https://drafts.csswg.org/css-align-3/#baseline-terms
The baseline sharing group is not equal to the baseline specified for
the item. It has to be calculated separately. The baseline sharing
group determines on which side of the block the item is aligned, but the
specified baseline is still used to determine the baseline of the item.
Depends on D200767
Differential Revision: https://phabricator.services.mozilla.com/D200768
https://drafts.csswg.org/css-align-3/#baseline-terms
The baseline sharing group is not equal to the baseline specified for
the item. It has to be calculated separately. The baseline sharing
group determines on which side of the block the item is aligned, but the
specified baseline is still used to determine the baseline of the item.
Differential Revision: https://phabricator.services.mozilla.com/D200768
https://drafts.csswg.org/css-align-3/#baseline-terms
The baseline sharing group is not equal to the baseline specified for
the item. It has to be calculated separately. The baseline sharing
group determines on which side of the block the item is aligned, but the
specified baseline is still used to determine the baseline of the item.
Differential Revision: https://phabricator.services.mozilla.com/D200768
This avoids using raw integer values which might cause bugs.
Also removed a clang-format: off block for better formatting.
Differential Revision: https://phabricator.services.mozilla.com/D200767
This avoids using raw integer values which might cause bugs.
Also removed a clang-format: off block for better formatting.
Differential Revision: https://phabricator.services.mozilla.com/D200767
Before this patch, when we baseline-aligned items in a grid, we were careful to
include items from subgrids in that alignment geometry. However, we ended up
dropping the baseline alignment metrics for those subgrid items on the floor,
per the code-comment and TruncateLength call here:
https://searchfox.org/mozilla-central/rev/b580e3f77470b2337bc8ae032b58a85c11e66aba/layout/generic/nsGridContainerFrame.cpp#3744-3747
This patch makes us propagate subgrid items' baseline-alignment metrics to
their actual GridItemInfo structs (which canonically live in the Subgrid()
frame-property on their direct subgrid parent).
Now that those baseline-alignment metrics are having an effect, we can also see
that the (previously-ignored) metrics are wrong in some cases -- they don't
properly account for various forms of padding on subgrid containers of
baseline-aligned grid items. That's tracked in bug 1871719, and that's the
reason this patch has several WPT subtests, which were previously passing.
(They were passing just by chance, since our previous trivial-fallback behavior
happened to place some items at the correct start/end-aligned location, and our
new baseline-aligned location happens to be incorrect due to bug 1871719.)
Since this patch is regressing those cases: out of an abundance of caution, I'm
putting the new behavior behind an about:config preference
"layout.css.grid-subgrid-baselines.enabled" (defaulting to true in Nightly,
false in other builds), so that this patch will have no behavioral effect for
users of release builds. We can remove the about:config pref once bug 1871719
is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D197233
This patch doesn't change behavior; it's just a rename.
We have an "entry-point" function CollectSubgridItemsForAxis that the outer
grid calls, and most of its work is done by a recursive helper function.
Before this patch, the recursive helper function has nearly the same name but
with the word "Items" removed, which doesn't make any sense, since it's still
collecting items from subgrids.
Let's just rename the recursive helper to match its entry-point, with a
"Helper" suffix, and document that it's a recursive helper. This makes the
function name a little longer, but not too much longer.
(I'm bothering to do this because the next patch in this series will add a
similar pair of functions, and I want the new functions to use the same naming
scheme as these existing functions.)
Differential Revision: https://phabricator.services.mozilla.com/D197232
This patch doesn't change behavior.
Before this patch, we're appending to the array that we're iterating over,
which is risky, though it happens to be safe right now since we don't use
any of the newly-invalid-data after the array is mutated.
This patch just uses a less risky approach (appending to a temporary array)
to avoid this fragility.
Differential Revision: https://phabricator.services.mozilla.com/D197217
When the subgrid gap forces a track to have a negative size, the old code was
clamping the track-size (`mBase`) to 0, but it was still placing that track at
`mPosition` that reflected its theoretical negative-size (shifting it
startwards). This patch removes that startwards shift.
Note on the tests: the existing grid-gap-011.html doesn't test the code change
around `lastTrack`. That is, we still pass the test without the position fix to
`lastTrack`. Hence I added grid-gap-012.html, which is adapted from
grid-gap-011.html, but with the subgrid gap changed to 250px (larger than the 2x
track size to test the position of the last track). Both Chrome and Safari
already pass the test.
Differential Revision: https://phabricator.services.mozilla.com/D197084
This is a slight change to our "clamping over-large grid" procedure (
https://www.w3.org/TR/css-grid-2/#overlarge-grids ) to more closely match the
spec requirements.
Per spec, we use this same procedure for two different things:
(a) to clamp the placement of grid items that are using extremely large grid line indices -- beyond 10,000.
(b) to clamp grid lines that are simply outside the bounds of their subgrid.
(Of course (b) is much more mundane, but the spec says to "[use] the same
procedure" at https://www.w3.org/TR/css-grid-2/#subgrid-implicit )
Before this patch, we were preemmptively clamping each of a grid item's
specified grid-lines at the moment that we resolve the individual line. This
approach doesn't quite match the #subgrid-implicit spec text linked above,
which says to create implicit grid lines (i.e. lines *beyond the clamp-limits*)
as-needed when placing the grid item; and only clamp once we've determined the
grid area (i.e. once we've resolved all of the grid lines).
The distinction is subtle, but it makes a difference for cases like the bottom
half of https://bug1800566.bmoattachments.org/attachment.cgi?id=9369740 , where
we have to search backwards from the end line in order to find a named line to
use as the item's start-line. The outcome ends up wrong if we clamp the end
line before we do that search (as we were doing before this patch) vs. if we do
the search first and then clamp the range as a whole afterwards.
See comments in the patch for more details.
Differential Revision: https://phabricator.services.mozilla.com/D197044
This patch only changes behavior in cases where the following conditions hold:
(a) We're asking an item for its baseline, and the item has a writing-mode
that uses a central baseline (e.g. vertical-rl).
(b) We're asking for a baseline **in that item's inline axis**, i.e. a
measurement in the y-axis.
In this situation, the item really only wants to use central baselines for its
own block-axis baselines, not for its inline-axis baselines. So let's not
bother trying to generate central baselines in its inline axis.
This is documented to some extent in
https://www.w3.org/TR/css-writing-modes-4/#text-baselines, which describes
central baselines as being between the 'over' and 'under' edges (aka
'line-over' and 'line-under'), i.e. a measurement in the element's own block
axis.
This makes us pass WPT subgrid-stretch.html, because it happens to depend on
the baseline alignment of horizontal-writing-mode grids that have
vertical-writing-mode subgrids.
Differential Revision: https://phabricator.services.mozilla.com/D196932
Ting-Yu Lin