Editor: @wordpress/theme style enqueue missing

[wildworks]

From what I've researched, the DataView in the site editor has some layouts based on new design tokens from the @wordpress/theme package. For example, the new Stack component applies gaps using the --wpds-dimension-gap-{size} CSS variable. However, this CSS variable itself has not been enqueued, causing the layout to break.

If it is intended that UIs based on this new design token be exposed to WP 7.0, we will need to add wp-theme to ​$package_styles in order to enqueue these CSS variables.

For example, making the following changes will solve the problem:

src/wp-includes/script-loader.php

@@ -1776 +1776 @@
                        'wp-reusable-blocks',
                        'wp-patterns',
                        'wp-preferences',
+
                ),
                'format-library'       => array(),
                'list-reusable-blocks' => array( 'wp-components' ),
@@ -1783 +1784 @@
                'patterns'             => array( 'wp-components' ),
                'preferences'          => array( 'wp-components' ),
                'nux'                  => array( 'wp-components' ),
+
                'widgets'              => array(
                        'wp-components',
                ),
@@ -1885 +1887 @@
                'wp-reusable-blocks',
                'wp-patterns',
                'wp-nux',
+
                'wp-widgets',
                // Deprecated CSS.
                'deprecated-media',

cc @0mirka00, @aduth, @mciampini

[wildworks]

Template list page in the site editor. There's no spacing where there should be.

[aduth]

I think the proposed patch is certainly how we'll want to think about introducing the theme styles to all the Gutenberg app entrypoints. I'm a little hesitant about over-exposing the tokens now if it limits the ability to change them moving forward (e.g. there's still ​some discussion of typography naming).

I wonder if the changes proposed by @0mirka00 in ​Gutenberg#75589 would work as a solution here. The goal of that pull request is to add reasonable fallback values in exactly these types of scenarios where the token stylesheet may not be present. And with current usage, the fallbacks are exactly what the "true" values would be anyways.

I think that change would be reasonably contained to the new component implementations, but if that would be too significant a change to land and backport for 7.0, an alternative could be to temporarily (for 7.0) swap the implementation of Stack used in DataViews to use e.g. a local copy that doesn't depend on the tokens.

[wildworks]

an alternative could be to temporarily (for 7.0) swap the implementation of Stack used in DataViews to use e.g. a local copy that doesn't depend on the tokens.

Are there any components based on design tokens exposed in WP 7.0 other than the Stack components?

[0mirka00]

Are there any components based on design tokens exposed in WP 7.0 other than the Stack components?

Just Stack and Badge.

@aduth @mciampini and I agreed that the preferred solution would be to enable the fallback plugins (​https://github.com/WordPress/gutenberg/pull/75589) in the build script, rather than temporarily patch things in the actual source code. We were planning to enable those plugins anyway, so it's not a temporary "workaround" for this specific 7.0 problem that we'd have to revert later.

[wildworks]

Should/can we backport the fallback plugin to 7.0?

If it's possible, that's fine, but if it can't be backported, I think it would need special fix for 7.0.

[0mirka00]

So my understanding of the backport process is (could be wrong):

1. Add a backport tag to the PR.
2. These changes get cherry picked onto the wp/7.0 branch.
3. Packages get rebuilt from the wp/7.0 branch and are published to npm.
4. WP Core syncs these new npm packages for the release.

So long as step 3 is using the build tooling from the wp/7.0 branch itself, it should technically work.

[wildworks]

It's important to note that from the Beta1 phase onwards, only bug fixes that occurred in that release are permitted.

​https://make.wordpress.org/core/handbook/about/release-cycle/block-editor-release-process-for-major-releases/#:~:text=After%20the%20first%20Beta%2C%20you%20can%20only%20include%20bug%20fixes%20for%20issues%20that%20regressed%20during%20the%20Alpha%20phase.%20It%E2%80%99s%20essential%20to%20know%20if%20the%20bug%20you%20are%20reviewing%20affects%20the%20latest%20stable%20release%20of%20WordPress.

Therefore, if ​GB 75589 is considered a major enhancement, it may not be possible to cherry-pick ​GB 75589 into 7.0 in the first place. In that case, we'll need to submit a PR to the wp/7.0 branch directly with a temporary fix for the 7.0 release.

cc @youknowriad

[0mirka00]

If the bug here is defined as "certain parts of the UI aren't rendering correctly without the design tokens stylesheet", then both approaches are equally just bug fixes. Having fallbacks in the built stylesheets isn't adding new features in any way, and is functionally equivalent to manually addressing those CSS variables in the source code.

Adding new plugins to wp-build could indeed be considered a new feature, but still only a new feature for wp-build, which is not part of the WP release.

Just leaving a trace of our justification here, so we can point to it.

[wildworks]

This ticket was resolved by the following two Gutenberg PRs:

• ​https://github.com/WordPress/gutenberg/pull/75589
• ​https://github.com/WordPress/gutenberg/pull/75879