Request For Comment: Content Widths and Child Themes

[douglas-johnson]

Problem To Solve

We would like the default content width and wide content widths to be different on Creepy Catalog.

So far those two values ( 32rem and 64rem respectively ) have been set in the parent theme and reused as LESS variables in the child themes.

We believe slightly wider default paragraphs that allow for more words per line would be a better reading experience on Creepy Catalog. In discussion with editorial and sales, it was also expressed that we would use the wide width for more images if the difference in size wasn't as large. A goal might be: make sure its possible to see the whole image and fit a caption or heading on screen at the same time on landscape tablets or laptops.

On the otherhand, we do not want to change these values for Shop Catalog where we need the wide width to be large for displaying a grid of products.

So, how could we make it possible for child themes to either inherit the parent theme widths, or change them for their specific needs?

Context Regarding Theme Settings

In WordPress 5.8, the theme.json file was introduced to partially replace the use of add_theme_supports for block editor settings. Adding theme.json is a step toward Full Site Editing which is a long term goal of WordPress where the block editor can used to edit... the full site.

https://make.wordpress.org/core/2021/06/25/introducing-theme-json-in-wordpress-5-8/

How It's Related

There is a "layout" setting in theme.json that lets you setcontentWidth and wideWidth. Those sizes are applied to the block editor. It is up to the theme developer to apply those values on the front-end.

https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/#settings

Issues With That

• Just adding a theme.json file changes the markup of some blocks. For example the group block loses it's __inter-container element which we rely on in some of our CSS.
• Adding a layout setting to your theme.json lets the editor know that you support __experimentalLayout features. This allows authors to change the content and wide width settings within group blocks. That's all well and good except the related CSS forces a centered layout.
  • I opened an issue with WordPress about that.
  • We can remove support for __experimentalLayout in the group block through our theme functions file.
• Child themes do not inherit theme.json settings from their parent. They have to have their own file.
• The layout settings values are not made available to the theme on the front-end through CSS custom proprties the way font size, colors and gradients are.
  • We can work around that by adding the layout sizes to CSS custom properties ourselves. I've done that in the 0.6.0-beta1 tag: https://github.com/thoughtis/cata/blob/0.6.0-beta1/theme.json

References

• https://github.com/WordPress/gutenberg/blob/%40wordpress/block-library%404.0.0/packages/block-library/src/group/edit.js#L87
• https://github.com/WordPress/gutenberg/blob/%40wordpress/block-library%404.0.0/packages/block-library/src/group/edit.js#L33
• https://core.trac.wordpress.org/ticket/53748
• https://core.trac.wordpress.org/browser/tags/5.8/src/wp-includes/class-wp-theme-json-resolver.php#L349

Options

Option A - Use Theme.json

• Add theme.json to Cata theme and all child themes.
• Set layout and font sizes in all themes.
  • Optionally set colors and gradients. Not all child themes support them.
• Update all theme CSS to use latest block markup
  • Ex: no *__inner-container block in groups.
• Make Content Width and Wide Width available as custom CSS properties.
• Use those custom properties through parent and child themes.

Pros

• Get on board with the latest WordPress updates.
• Theme.json is more convenient than add_theme_support for fonts, colors, and gradients.
• Font Family support coming soon which we want too.

Cons

• More work since all themes need to be updated.

Option B - Use Customizer

• Add settings to the Customizer for Content Width and Wide Width to Cata theme.
• Make those values available as CSS custom properties in admin and front-end.
• Apply those values to the editor using editor-styles.
• Apply those values to the front-end through the parent and child themes.

Pros

• Less work now because there's less updating in child themes.

Cons

• Creates tech debt because we will still need to update for WP eventually.

[richdacuban]

@douglas-johnson This is a great write-up, thanks for it.

I generally lean towards the solution that would provide the best, soonest benefit to our users, the editorial team in this case; so reflexively, I gravitate towards using the wp customizer to get the custom widths set for use ASAP. On further contemplation though, despite the initial glut of work to update all our WP site themes to use Theme.json(s), updating to the newer feature which is likely to have support improved and expanded functionality added over the next several WP versions seems best.

Especially when one considers making any additional site customization in future (this is assuming full coverage for add_theme_support features is eventually filled out, the list of equivalencies in theme.json is pretty limited currently).

So, I am in support of migrating to Theme.json throughout, and removing add_theme_support calls where possible.

[douglas-johnson]

Thanks @richdacuban !

[douglas-johnson]

Additional context for child themes: WordPress/gutenberg#25612