Consider allowing themes to enqueue stylesheets in theme.json

[kjellr]

If all of the add_theme_support() options from https://github.com/WordPress/gutenberg/issues/26901 are incorporated into theme.json, the only things a theme must include in a functions.php file are its stylesheets.

For the sake of discussion, would it be possible (and a good idea) to allow block-based themes to define their front-end and editor stylesheets directly from within theme.json?

[scruffian]

Will themes still need style sheets?

[kjellr]

Many themes will still have stylesheets for things like transition and animations, etc. Global Styles won't cover all of those use cases.

But at a baseline, they'll need a style.css to house the standard DocBloc. WP won't currently recognize a theme without one. (I guess this could be changed. 😄)

[scruffian]

In which case can we just always enqueue style.css without needing a line in functions.php? Other stylesheets could be @imported into style.css...

[kjellr]

Yeah, currently, @imported stylesheets aren't loaded into the editor at all, so that would need to be changed. I filed https://github.com/WordPress/gutenberg/issues/26963 to discuss that point.

[jorgefilipecosta]

The issue with imported stylesheets is that a plugin would have no way to not enqueue a specific stylesheet.

[jorgefilipecosta]

But at a baseline, they'll need a style.css to house the standard DocBloc. WP won't currently recognize a theme without one. (I guess this could be changed. 😄)

I think we should allow the docblock to come from theme.json in order to allow a theme without any CSS and just with a theme.json file.

[jorgefilipecosta]

I think it would be a good idea to allow theme.json to load external stylesheets. I imagine something like:

styles: {
    "$handle": {
        "src": "/assets/alignments-front.css",
        "ver": (optional contrary to wp_enqueue_style defaults to the theme version instead of the core version WordPress version, we know that on theme.json we are in theme code and the theme version is more important).
        "media": (optional same as wp_enqueue_style media)
    }
}

Styles loaded in this way would behave exactly like the styles added in PHP, and plugins could interact with them in the same way.

cc: @mtias, @youknowriad

[youknowriad]

I don't know if this is a good idea, I need to think about it more but what I know is that the capabilities of theme.json are growing constantly and IMO before thinking of adding new features, let's make sure what we already have works perfectly. (For instance, do we really want to show all global styles UI like we have now, or do we want it to be controlled by the theme?)

[oandregal]

I'd say the theme.json model (configs per block/context) is at odds with loading stylesheets that don't match those elements. I'd also refrain from trying to do this at the moment.

A different approach that was mentioned https://github.com/WordPress/gutenberg/issues/26901 is whether we can/should do some things automatically (like enqueueing block styles, etc) if a theme has a theme.json. I think this could be good to explore to understand the trade-offs better.

[oandregal]

Cross-referencing this convo https://github.com/WordPress/theme-experiments/pull/81#discussion_r523098646 TLDR: if we want to remove the stylesheets, we have to update the logic for what WordPress core & WordPress theme directory considers a minimum theme.

[jorgefilipecosta]

For instance, do we really want to show all global styles UI like we have now, or do we want it to be controlled by the theme?

Hi @youknowriad,

The UI controls are already controlled by the theme right now.

• to disable color options: a theme can pass an empty array of available colors and disable custom colors.
• to disable font sizes, a theme can pass an empty array of font sizes, and disable custom font sizes.
• to disable line-height, a theme can set customLineHeight to false.
• to disable padding, a theme cans set customPadding to false.

Themes can control all these settings at the global level and at the block level, e.g., a theme can disable all these settings at the global level but enable for specific blocks or the contrary. There is no difference between enabling/disabling at the global styles or block level. E.g., if a theme disables line height for a paragraph, it will stop being available in the paragraph block inspector and in the global styles paragraph panel.

Would you recommend a change in the API's we have to disable UI elements from the user, or is there anything you think is missing?

[youknowriad]

How do I do that now?

• Enable color options, font sizes, line-height and padding everywhere in the post editor.
• Only allow the user to change the "main color" + "global font sizes" at the site editor level.

[overclokk]

@import inside a stylesheet should never being used.

[oandregal]

I learned that we have an issue with dynamic styles. It affects both the ergonomics of theme authors and the iframe work: https://github.com/WordPress/gutenberg/issues/18571

In talking to @ellatrix about this, a system along the lines of @jorgefilipecosta proposal above could help address all these issues:

• themes won't need to use functions.php to enqueue styles
• there's a handle that we can use to load styles in the iframe
• themes that want to use dynamic styles have also a handle they know will be managed for them (either to load them in the iframe or to wrap them with the .editor-styles-wrapper class, which is something that's lacking with the current add_editor_styles wrapper).

I was initially thinking that we could use a similar method as of the block.json for blocks: just having a stylesheets key to declare a handle. But it sounds like allowing to declare the styles to be enqueued solves more issues.

[ellatrix]

Would be cool to do this.