Idea: Using block markup and block CSS classes outside the content

[carolinan]

This idea is based on 3 things:

1. By using block markup for sections outside the content, the theme can take advantage of CSS that is already in WP core.
   For example, a header and footer with two or 3 columns can be built using markup and CSS that matches a columns block.
   It reduces the CSS that needs to be in the theme.

2. It helps prepare the theme for when global styles is available.
   By using the same CSS classes used by different blocks, global styles can be used to style the entire site and not only the content. -Without extra options in the customizer.

And thirdly, it makes creating an FSE version easier since the PHP version would already use block markup.

It might not be possible to use block markup for everything but that's OK.
It does not limit us to using only block CSS classes.
It needs testing through different WP versions to assure backwards compatibility

I would be interested in hearing more pros and cons.

Partial footer, where the columns flex styles would be provided by the block library style.

`

	<?php get_template_part( 'template-parts/footer/footer-widgets' ); ?>

	<div class="wp-block-columns site-info">
		<div class="wp-block-column imprint">
			<a href="<?php echo esc_url( __( 'https://wordpress.org/', 'twentytwentyone' ) ); ?>" >
			<?php
			/* translators: %s: WordPress. */
			printf( __( 'Proudly powered by %s', 'twentytwentyone' ), 'WordPress' );
			?>
			</a>
		</div>
		<div class="wp-block-column site-name">
			<?php
			$blog_info = get_bloginfo( 'name' );
			if ( ! empty( $blog_info ) ) {
				?>
				<a href="<?php echo esc_url( home_url( '/' ) ); ?>" rel="home"><?php bloginfo( 'name' ); ?></a>
				<?php
			}
			?>
		</div>
		<div class="wp-block-column copyright">
			<?php
			/* translators: 1: Copyright date format, see https://www.php.net/date, 2: Site name */
			printf(
				__( '&copy; %1$s %2$s', 'twentytwentyone' ),
				esc_html( date_i18n( _x( 'Y', 'copyright date format', 'twentytwentyone' ) ) ),
				esc_html( get_bloginfo( 'name' ) )
			);
			if ( function_exists( 'the_privacy_policy_link' ) ) {
				the_privacy_policy_link();
			}
			?>
		</div>

	</div><!-- .site-info -->
</footer><!-- #colophon -->`

[youknowriad]

I don't think that's a great idea personally unless it's already an FSE theme. We were looking at ways to lazy-load block assets and doing this make such thing impossible. The framework needs to know where blocks are being used.

That said, theme authors are probably already doing so and when we introduce lazy-loading, we'd have to figure out a way to "warn" them.

[carolinan]

Yes you are right that is a valid point that I did not consider.
-And loading the styles that way is a feature that I would also want to see happen.

It also means that global styles will be less useful for non FSE themes.

@aristath posted an idea where the theme would be able to choose how the CSS is loaded, with theme support and filters
WordPress/gutenberg#25118.

But for this theme both backwards compatibility and future proofing is important.

[aristath]

It is possible to have both....
If the template-part is written in proper block format it can be done.
The idea is to do what we'd normally do on an FSE theme, so just copy-paste the block-editor output to a template.
The only difference is that instead of pasting things in a .html file we'd paste them in a .php file, and we'd be able to use translation functions etc.

Then instead of loading template parts using get_template_part, we'd add a proxy function:

function twentytwentyone_do_the_template_part_blocks( $template ) {
	ob_start();
	get_template_part( $template ); // So that translations and logic works
	echo do_blocks( ob_get_clean() );
}

The above method is a semi-FSE approach to building a theme and can take advantage of things we do in the block editor (like lazy-load assets on block-render)
It will also make things a lot easier to build/convert to FSE once that is complete since things will already be in block format.

[carolinan]

This interests me because one of my first ideas (months ago when it still felt like we had all the time in the world) was to create the FSE theme first and just add the needed PHP functions, since the styles would be the same.

[aristath]

This interests me because one of my first ideas (months ago when it still felt like we had all the time in the world) was to create the FSE theme first and just add the needed PHP functions, since the styles would be the same.

Making an FSE theme work without FSE actually existing is definitely possible.
It will take some extra PHP files, but if there's an html file with block syntax you could create the corresponsing php file and all it would need inside a page.php file would be something like this:

<?php
ob_start();
include get_theme_file_path( 'page.html' );
echo do_blocks( ob_get_clean() );

Or even more abstract, a function inside the functions.php file can hook in the templates loader, and if an html file exists do the blocks overriding automatically.
Though I'd prefer just doubling the files... It's simpler, child-theme friendly and it's a solution I've been using for quite a while without issues.

[youknowriad]

While I think that's clever, I'm not sure it's something we should on a WP default theme where I think IMO simplicity matters.

[carolinan]

@aristath Do you have an example theme ready where the files are doubled?

[aristath]

I just tried this with a test theme.
While it does work, if a block does not exist in wp-core it doesn't get rendered. In my case it only worked fine because it was for a semi-static site and the templates contained core blocks only.

So until the FSE blocks like core/post-content make it in wp-core this is not a viable solution.
The only alternative if we want to do a pure-FSE theme is to require Gutenberg be installed as a plugin with the FSE experiment enabled. But that is not something we should do in a default core theme...

We can still use this method for template-parts that only include blocks available in wp-core, but it wouldn't be worth the mess.

[pattonwebz]

I experimented recently with building an FSE theme that has block markup in the templates and ran into a number of issues. The first problem is that class names have changed in recent past and are likely to change again in future for a number of the blocks. Chasing a moving target of the classnames, markup and styles seems unfeasable.

[carolinan]

To be able to change colors of the header and footer area with global styles, only a group block CSS class or perhaps a column CSS class would be needed :) Those are not likely to change. That is the absolute simplest version, but with the json file there are many more possibilities.