We rely on the min/max sizes in the RepeatTrackSizingInput to determine
how many auto-repeat items we can place, so we have to make sure we take
aspect-ratio into account. So if we have aspect-ratio, we need to take
it into account and use the ratio-determining size to compute the
transferred min/max/preferred size.
However, we don't have the information of containing block now, and
we will fix the case if the ratio determining size has percentage in the
following patch.
Differential Revision: https://phabricator.services.mozilla.com/D195199
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
