Conditionally Include Custom Styles/Stylesheets for Templates and Template Parts (akin to wp_enqueue_block_style())

[jeremyescott]

What problem does this address?

When developing block themes, I've found myself wishing I could add styles for templates and template parts akin to how we wp_enqueue_block_style(). With the block editor including only necessary CSS for performance, this pattern was one I want to be available for templates and template-parts.

For an example from a real-world project, Wikimedia Enterprise, an FSE website I constructed:

On the "Docs" page template, the design required a "sticky" sidebar. This is not a pattern available to the editor, but I was able to largely construct the layout without the "sticky" CSS. However, I needed custom CSS added to make the "sticky".

I could have of course added it to style.css, but with a goal of style.css one day being only necessary to define the theme, I wanted to find an alternative, not only to force myself into the design pattern but also to enjoy the benefits only loading the CSS when needed (and not on pages that don't need it).

My solution was to conditionally enqueue the CSS when is_page() and is_page_template('docs'). This can and should be easier, especially in the day and age of theme.json.

I also feel like like this level of customization is similar in spirit to @carolinan's suggestion on #43347.

What is your proposed solution?

In addition to @carolinan's suggestion...

• Add a function similar to wp_enqueue_block_style() for each template-parts and templates (perhaps wp_enqueue_template_style() and wp_enqueue_template_part_style()) that will conditionally add CSS specific for a template, and only when the template is included in render.

• Add an arg to the templateParts and customTemplates array args of theme.json that will enable developers to include CSS conditionally when a template is included, either as a separate file, or as text, for example:

  "customTemplates": [
  {
    "name": "docs",
    "title": "Docs Pages",
    "postTypes": [
      "page"
    ],
    "stylesheet": "{slugName | url | CSS text string"
  }
  ]

  and

  "templateParts": [
  {
    "name": "docs-header",
    "title": "Docs Header",
    "area": "uncategorized",
    "stylesheet": "{slugName | url | CSS text string"
  }
  ]

[ajlende]

This also seems conceptually similar to the style property on block.json just applied to templates and template parts

[scruffian]

I'm not sure about this. One of the goals of block themes is to reduce the need for loading lots of custom CSS. This seems to encourage an approach which uses CSS rather than relying on Global Styles and block settings to provide the styles. Is there an example of the kind of CSS you'd want to include?

I see https://github.com/WordPress/gutenberg/issues/43347 as a slightly different idea as to me the way we'd achieve that is by allowing different settings in Global Styles for different template parts, not using CSS.

[jeremyescott]

@scruffian Thanks for your comment, hopefully I can both agree with you and make the case for this suggestion as well!

So the goal of the block themes is to make a reasonably "no-code" site editing experience. And that is awesome! It is why I love it, even though I'm a very experienced coder.

WordPress has lots of types of users. We run the gamut from the basic blogger to the coders using it as an app development platform. The high end enterprise user, like Wikimedia Foundation in the project I linked to above, will trust WordPress but demand a lot from it. And good! This is why we developers have job security.

So what happens when the high-end user wants a functionality that isn't supported by the block editor? Few options:

1. They find or build a custom block.
2. They abandon the block editor and build traditional themes.

As our collective skills as a community grow and as tools like ACF's block builder become commonplace, option 1 is more and more common, but what happens when that custom functionality is more than just a block, but is needed at the template level? Right now, if we want to use a block theme, there are fewer options:

1. Add a bunch of custom css to style.css
2. Do something more complicated.

When making the Docs pages for Wikimedia, I needed CSS code to handle the responsiveness and sticky features of the sidebar. Here is how I did it, using the option 2 of "something more complicated."

add_action( 'wp_enqueue_scripts', __NAMESPACE__ . '\docs_scripts_styles' );
/**
 * Enqueue Docs Template Styles/Scripts
 *
 * @since 2020-06-13
 *
 * @return void
 */
function docs_scripts_styles(): void {

    if ( ! is_page() || ! is_page_template( 'docs' ) ) {

        return;
    }
    // Previously registered
    wp_enqueue_style( 'wikimedia-enterprise-theme-style-docs' );
}

As we know, this includes the file in the head <link rel="stylesheet" /> as a separate download and not as block of CSS in a <style> tag, which is the behavior of the custom rules for section blocks and what happens when CSS scripts are included with wp_enqueue_block_style(); So this is an ever so slightly heavier load, especially when my custom stylesheet has under 200 lines.

I agree you that we are reducing the need for custom CSS, and this feature request isn't increasing the need for custom css, but it is making it easier to include it if the design and functionality call for it. While #43347 is so awesome and I hope it gets it added, that issue would not replace my use case. The designers called for things not supported by block themes but that, with a few lines of css, was possible!

[scruffian]

I think this might be the kind of thing that would be good to explore in a plugin to begin with to get a sense of how many people would want it.