FSE: Add support for body_class and post_class

[scruffian]

What problem does this address?

Classic themes add no-js, singular, hfeed, has-main-navigation and no-widgets classes to the body. Gutenberg should also do this for block themes.

We also need to look at what we add for post_class and add support for that too.

From #22724.

[carolinan]

FSE themes already use the body_class and this can still be filtered
https://github.com/WordPress/gutenberg/blob/master/lib/template-canvas.php

[carolinan]

The PR just adds the existing get_post_class() function, I wonder if we need to consider what classes are added and if any of them are redundant?

[lukecarbis]

@carolinan Revising post classes might cause backwards compatibility issues for some plugins or child themes that rely on particular classes. Not saying we shouldn't revise, just wanted to keep that in mind.

[carolinan]

There will still be issues because traditionally themes have a an article (or div) around both header, content and meta information. FSE does not have "post areas", the only consistent wrapper is the div that already has the entry-content class.

It is possible to place it on the query loop list markup, but then it will not affect single views.

[aristath]

Do we even want to add all these classes?
FSE is an opportunity to get rid of all the things that have plagued WP for ages - including a dozen classes that no longer make a lot of sense. 🤔
FSE doesn't need to be backwards-compatible...

[carolinan]

There are two sides to that 🤔
If theme developers adds an FSE template to an existing PHP/classic/traditional theme, what parts of the themes existing CSS should be applied to that template?

[scruffian]

I assumed there were accessibility reasons for supporting no-js, and schema reasons for singular and hfeed.

[carolinan]

You are already able to add those, by filtering the body class.

[aristath]

The no-js class is usually added by themes/plugins AFAIK, was it ever added by core? I know core adds it in the dashboard, but I don't think it adds it to the frontend, unless I missed that somewhere?
The singular class has no semantic value, it was always just a convenience for themes that wanted to target all singular posts.
hfeed was a microformats class but I believe those microformats are no longer used anywhere, or in case they are used they are not fully implemented and are becoming obsolete. Removing the hfeed class should not be a problem 👍

[scruffian]

Thanks. My suggestion is that core adds no-js for consistency and convenience if that's something that many plugins and themes do. However if it's not something we'll continue to need then I'm happy for us not to.

[aristath]

If core adds the no-js class, then core will also need to add the script to remove that when there is JS 😅

<script>document.body.classList.remove('no-js');</script>

I don't believe we want to add any scripts on the front - no matter how simple they are. At least not at this point AFAIK 🤔

Without the script that class is meaningless and will do more harm than good... Core doesn't need that class on the frontend because it doesn't load any scripts on the front for blocks, so I think it would be fine to skip it. If any plugins/themes need to check for that class they always add it on their own

[scruffian]

I guess this can be closed then...

[carolinan]

I'm still confused.
There is no change for body_class. It will keep working as it does today.

The question remains if the post_class() should be added or not and on which block -post content, or querly loop?

Before:
<div class="entry-content alignfull wp-block-post-content">

After:
<div class="entry-content post-151 post type-post status-publish format-standard hentry category-uncategorized alignfull wp-block-post-content">

These are the classes I was wondering if we really want to add:
post-151 post type-post status-publish format-standard hentry category-uncategorized

Perhaps only the post id and type should be added? Post format?

[overclokk]

I agree with @aristath FSE should be as cleaner as possible, adding thoose CSS class should not be made by core when possible.

@carolinan

These are the classes I was wondering if we really want to add:
post-151 post type-post status-publish format-standard hentry category-uncategorized

I don't think we need them, for a client I added a custom css class with post_class filter to do "even odd" effect on posts, I think if we can rely on that filter there's no nedd to add them by default.

[carolinan]

@scruffian I am not sure why this was closed, was a conclusion reached elsewhere? I'd like to know if I should also close #29412.

[scruffian]

I closed it because I hadn't yet seen a good example of when they are needed. I see in #29412 you're adding post-151 post type-post status-publish format-standard hentry category-uncategorized - what would these be used for?

[carolinan]

Those are default classes, see https://developer.wordpress.org/reference/functions/get_post_class/

Without the post_class function, the filter to adjust the classes also can't be used.

The hentry should probably avoided.
I can definitely see use for having a CSS class for sticky, format, category, password protected so that posts can be styled differently.
Without this, there is no way to programmatically identify a sticky post.

But this still leaves the question about where these classes should be output. On the content block or somewhere else?

[carolinan]

format-standard usage:
https://wpdirectory.net/search/01F1A72DD2E7H8EB1XEG2N4ESW

type-post usage:
https://wpdirectory.net/search/01F1A745WRJ828GRC6K4GFTDHB

[justintadlock]

I closed it because I hadn't yet seen a good example of when they are needed.

Asking why we need conditional classes? Simple. A user asks how they can add a purple border to only their posts with the "Super Duper" category. I say, "Add this code to your CSS:"

.category-super-duper {
	border: 1px solid purple;
}

Without the class, I say, "Sorry, WordPress no longer allows you to do cool stuff like this. Look for another piece of software or switch to a classic theme."

If anything, I'd like us to adopt an entire attribute system, not just limiting to classes. The class system is overly limiting for more advanced features. I doubt that will happen, so let's keep the system in place. We can reevaluate and remove core-output classes. However, theme authors should be able to filter them.

[justintadlock]

But this still leaves the question about where these classes should be output. On the content block or somewhere else?

On the content block would be the wrong place and would create back-compat issues for any old themes transitioning to FSE. It should be on a wrapper element for the entire post. Not sure how that will work. There really should be a "Post" block, even if it only exists as a container for nested blocks.

[scruffian]

A user asks how they can add a purple border to only their posts with the "Super Duper" category

I'd expect this kind of feature to live in the query block, not as part of a theme.

[justintadlock]

I'd expect this kind of feature to live in the query block, not as part of a theme.

The feature I described really isn't part of the theme. Users can customize their CSS regardless of theme.

However, I cannot imagine how crazy the Query block would have to be to cover the endless amounts of customization for the conditionals that exist. This is just one extremely tiny example for a basic border. Will the Query block have conditional styling options for every single class that currently exists? We know it won't. It never will. Each use case on its own is an edge case. Altogether, they represent a needed feature.

[scruffian]

My suggestion is that the query block could output a class, like we currently do on the body...

[justintadlock]

My suggestion is that the query block could output a class, like we currently do on the body...

The Query block wraps all posts, not individual posts. Or, are you talking about having the Query block inject the post class around each post?

[aristath]

The query-loop block already wraps each post in a li, so we can add classes there. See PR #30497 for a possible solution.