1607954 - [css-grid-2] Investigate supporting Masonry layout in a grid container

Status: RESOLVED FIXED

(Core :: Layout: Grid, enhancement, P3)

Description

[Mats Palmgren (inactive)]

It seems this is quite feasible to implement. I've posted some details at:
https://github.com/w3c/csswg-drafts/issues/4650

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase #1: Fragmented grid with masonry inline-axis

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #2: Fragmented grid with masonry block-axis

Comment 3

[Mats Palmgren (inactive)]

Attachment: Video capture of Testcase #1

Comment 4

[Mats Palmgren (inactive)]

Attachment: Video capture of Testcase #2

Comment 5

[Mats Palmgren (inactive)]

Attachment: 'align-tracks' testcase

Comment 6

[Mats Palmgren (inactive)]

Attachment: Screenshot of 'align-tracks' testcase

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase #4: 'align-tracks: stretch'

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase #5: 'justify-tracks: stretch'

Comment 9

[Mats Palmgren (inactive)]

Attachment: Video capture of Testcase #4

Comment 10

[Mats Palmgren (inactive)]

Attachment: Video capture of Testcase #5

Comment 11

[Mats Palmgren (inactive)]

Attachment: Same as Testcase #4 but not using the `grid` shorthand

Comment 12

[Mats Palmgren (inactive)]

Attachment: Testcase: Baseline groups

Comment 13

[Mats Palmgren (inactive)]

Attachment: Screenshot: Baseline groups

Comment 14

[Mats Palmgren (inactive)]

Attachment: Testcase: align-tracks multiple values

Comment 15

[Mats Palmgren (inactive)]

Attachment: Testcase: align-tracks multiple values

Comment 16

[Mats Palmgren (inactive)]

Attachment: Screenshot: align-tracks multiple values

Comment 17

[Mats Palmgren (inactive)]

Attachment: Bug 1607954 part 1 - [css-grid][css-align] Implement style system support for Masonry layout. r=emilio

This implements support for this CSS Masonry layout proposal:
https://github.com/w3c/csswg-drafts/issues/4650

It's enabled by default only in Nightly for now to gather feedback
and testing.

I've intentionally left out a shorthand (place-tracks?) for now until
we have a draft CSS spec for this.

Comment 18

[Mats Palmgren (inactive)]

Attachment: Bug 1607954 part 2 - [css-grid][css-align] Implement Masonry layout. r=dholbert

Depends on D67061

Comment 19

[Mats Palmgren (inactive)]

Attachment: Bug 1607954 part 3 - [css-grid][css-align] Add tentative tests and update devtools support files for Masonry layout. r=emilio,dholbert

Depends on D67062

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/84708ff0ef43
part 1 - [css-grid][css-align] Implement style system support for Masonry layout.  r=emilio
https://hg.mozilla.org/integration/autoland/rev/3216ec9f1999
part 2 - [css-grid][css-align] Implement Masonry layout.  r=dholbert
https://hg.mozilla.org/integration/autoland/rev/84d37ea90966
part 3 - [css-grid][css-align] Add tentative tests and update devtools support files for Masonry layout.  r=dholbert

Comment 21

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23286 for changes under testing/web-platform/tests

Comment 22

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 23

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/84708ff0ef43
https://hg.mozilla.org/mozilla-central/rev/3216ec9f1999
https://hg.mozilla.org/mozilla-central/rev/84d37ea90966

Comment 24

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 25

[Sebastian Zartner [:sebo]]

I've documented this as experimental feature at https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#Masonry_layout.

Sebastian

Comment 26

[Takanori MATSUURA]

This bug is fixed.
However the bug number still exists in toolkit/components/featuregates/Features.toml.

Comment 27

[Daniel Holbert [:dholbert]]

That's correct. Is that a problem? (This is a genuine question; I don't know if it is or not, since I'm not familiar with conventions that might exist around management of this Features.toml file.)

This bug is closed as fixed because this feature is implemented, though it's disabled-by-default (except in Nightly). It's in Features.toml to provide people a way to enable it and test it in other releases, if they want.

It's not clear how soon we might be able to enable this more broadly, in part because no other browser vendor has started working on the feature, to my knowledge. (Though it's gotten some discussion in the CSSWG standards body.)

If it's administratively useful for Features.toml to only link to bugs-that-are-still-open, we could definitely file a tracking bug to cover letting this feature masonry ship to release", though - just let me know.

Comment 28

[Takanori MATSUURA]

Oh, I misunderstood that features implemented and enabled on Nightly will be removed from about:preferences#experimental.
(But I personally think that features implemented and enabled on Nightly should be removed from about:preferences#experimental on Nightly. By doing so, the user will be aware that the bug is after its experimental stage and will be encouraged to report it.)

In BMO, I sometimes find the "Enable foo by default on nightly only." bug that blocks "Enable foo by default on release.".

Comment 29

[Daniel Holbert [:dholbert]]

If you have more general concerns or proposals about how to handle about:preferences#experimental, we should probably discuss them on https://groups.google.com/a/mozilla.org/g/dev-platform rather than as a back-and-forth on this one particular bug.

As long as I'm here, though, I'll reply in an attempt to clarify a few things:

(In reply to Takanori MATSUURA from comment #28)

Oh, I misunderstood that features implemented and enabled on Nightly will be removed from about:preferences#experimental.

I'm not aware of that being a policy; I see a handful of things checked-by-default there, in Nightly (not only this one feature).

(But I personally think that features implemented and enabled on Nightly should be removed from about:preferences#experimental on Nightly. By doing so, the user will be aware that the bug is after its experimental stage and will be encouraged to report it.)

I think this is coming from a misconception. It sounds like you might be thinking that if a feature is enabled-by-default in Nightly, then that's an indication that a bug is "after its experimental stage" -- but that's not actually the case. It depends on how the feature is flagged as being enabled.

If the feature is unconditionally enabled-by-default in mozilla-central (e.g. if it just has value: true in https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml ), then yes, you're probably-correct that the feature is no longer experimental (since it's riding the trains to release), and it'd be a good candidate for removal from the about:preferences experimental UI (if it happens to be listed there).

But if the feature is only conditionally-enabled via a guard like value: @IS_NIGHTLY_BUILD@ or EARLY_BETA_OR_EARLIER, then that means it's not-yet-ready-for-release and it's still quite-legitimately "experimental".

In BMO, I sometimes find the "Enable foo by default on nightly only." bug that blocks "Enable foo by default on release.".

Yeah; in this case, the "enable foo on nightly only" bug was bug 1672807. It looks like we don't have an "enable on release" bug; I'll go ahead and file one for tracking purposes.