Closed Bug 1607954 Opened 5 years ago Closed 5 years ago

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox77 --- fixed

People

(Reporter: MatsPalmgren_bugz, Assigned: MatsPalmgren_bugz)

References

(Blocks 6 open bugs)

Details

(Keywords: dev-doc-complete, Whiteboard: [layout:backlog:77], [wptsync upstream])

Attachments

(18 files, 1 obsolete file)

703 bytes, text/html
Details
846 bytes, text/html
Details
94.95 KB, video/ogg
Details
515.74 KB, video/ogg
Details
2.48 KB, text/html
Details
16.41 KB, image/png
Details
1.42 KB, text/html
Details
1.40 KB, text/html
Details
200.84 KB, video/webm
Details
165.54 KB, video/webm
Details
1.43 KB, text/html
Details
3.12 KB, text/html
Details
13.74 KB, image/png
Details
1.95 KB, text/html
Details
18.84 KB, image/png
Details
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review

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

Blocks: 1607971
Whiteboard: [layout:backlog:2020q1]
Attached file Testcase: align-tracks multiple values (obsolete) —
Attachment #9127912 - Attachment is obsolete: true

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.

Depends on: 1627581
Whiteboard: [layout:backlog:2020q1] → [layout:backlog:77]
Status: NEW → ASSIGNED
Depends on: 1632200
Depends on: 1633610
Attachment #9133701 - Attachment description: Bug 1607954 part 3 - [css-grid][css-align] Add tentative tests for Masonry layout. r=emilio → Bug 1607954 part 3 - [css-grid][css-align] Add tentative tests and update devtools support files for Masonry layout. r=emilio,dholbert
Pushed by mpalmgren@mozilla.com: 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
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23286 for changes under testing/web-platform/tests
Whiteboard: [layout:backlog:77] → [layout:backlog:77], [wptsync upstream]
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Upstream PR merged by moz-wptsync-bot

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

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.

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.".

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.

Blocks: 1627581
No longer depends on: 1627581
Blocks: 1632200
No longer depends on: 1632200
Blocks: 1633610
No longer depends on: 1633610
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: