Gutenberg: Feature parity between FSE Blocks and regular blocks

[mtias]

We have several new full site editing blocks that we need to match feature-wise with what regular blocks offer:

• [x] Site Title → Heading (@apeatling) https://github.com/WordPress/gutenberg/pull/22843, #23007
• [x] Site Tagline → Paragraph (@copons) #23788
• [x] Post Title → Heading (@apeatling @copons) #22872 #24246
• [x] Post Date → Paragraph (@copons) #23931
• [x] Post Author → Paragraph (@Addison-Stavlo) #22877, #23044
• [x] Post Content → Paragraph / Group (@noahtallen, #24014)
• [x] Post Excerpt → Paragraph (@Addison-Stavlo) #23945
• [x] Post Tags → Paragraph (@jeyip) #24069 #24082
• [x] Post Categories → Paragraph (@Copons) #24091

---

• [x] Comments → Paragraph / Group (@Addison-Stavlo) #24080 (follow up: #24101)
• [x] Comment Count → Paragraph (@Copons) #24167
• [x] Comment Form / Reply → Paragraph (@Copons) #24162 (follow up: #24221)

[aduth]

For technical implementation, I'd wondered if it might be something to implement as deferring to the implementation of another block. We have some of the pieces of this, e.g. <BlockEdit />.

But in most of these cases, is it really much more than <RichText />, with a particular configuration? It would be nice if we could leverage components for the shared baseline. The main unknown at this point would be in implementing common attributes, which I think could be addressed as part of proposals of #15450.

Ideally then, the implementation for _either_ the "Site Title" or "Heading" blocks could look something like:

function edit() {
    useTextAlignment();
    useTextColor();
    // useHeadingLevel(); // ???

    return <RichText { /* ... */ } />;
}

_(For demonstration only, not a finished API)_

[youknowriad]

@aduth Personally, I'm leaning more towards expanding the approach used in #21021 to all these customizations which is close to the proposal above with a bit less flexibility (support keys) but more capabilities, touching any part of the block registration/filters.

the missing piece is whether we can have something like the "save props" filter on the server to automatically augment the frontend output.

[aduth]

@youknowriad Yeah, in the context of this issue, I'm not so much concerned about the specific API for reusing common behaviors, but more to the point that we don't need "Site Title" block to be aware of a "Heading" block if each can be mostly recreated with relative ease by opting in to a combination of common components and block functionality.

In fact, I'm not much of a fan of using React hooks for this, since one of the requirements of this extensibility is in assigning new attributes to a block type, which is something which should be possible to be made known to the server-side.

[MichaelArestad]

Does this need design feedback here or can we provide feedback on individual PRs?

[mtias]

We need to map out what tools make sense for each.

[karmatosed]

I took a quick look at this to try and surface out what we could have on each block.

Default parity

Both the heading and paragraph block have the following:

Align: left/centre/right, Text styling: bold, italic, Link, Inline code, Inline image, Strikethrough, Text color.

There are also extra options for:

Hide Block Settings, Duplicate, Insert Before, Insert After, Edit as HTML, Add to Reusable blocks, Group, Remove Block.

FSE blocks

I would say the following should exist across all:

Align: left/centre/right, Text styling: bold, italic, Text color

The ones I am not as sure about would be:

Link, Inline code, Inline image, Strikethrough

The options probably should exist across all, but I could see an argument for trimming some of those.

[mtias]

There's a lot of those that don't make sense for the site / post blocks in the context of FSE. All the inline formatting tools, for example, don't make sense because the text is not selectable — only block level changes would apply.

[karmatosed]

In light of removing any inline my recommendations then would be:

Align: left/centre/right alone.

I do wonder about text color changing it all, but that can be later.

Options wise I would trim down to maybe just remove block as a starting point.

[dwolfe]

I touched on this in my most recent update on the placeholder blocks issue.

My thinking was very close to your original list, @mtias, with the exception of Tags and Categories - would those be lists?

[nosolosw]

I've added these blocks in https://github.com/WordPress/gutenberg/issues/22700 to keep track of the work related to style attributes.

[apeatling]

@karmatosed @mtias I'm starting with the Site Title block. Changing this to use RichText component instead of PlainText allows the block to support the standard tooling:

Reading above I'm unclear on what the decision is for support. The text in this block is selectable and editable so reducing to alignment only seems limiting.

[apeatling]

The issue with supporting these formatting options for something like Site Title is WordPress escapes the entities so you get this on the front end:

I think we're able to support text alignment via classNames in the wrapper, and also support the changing of the tag used for the title. @mtias mentioned not exposing this in the UI to start.

[mtias]

Yes, we cannot use rich text here. We can support block-level color tools and font-sizes, though.

[noahtallen]

Align: left/centre/right alone.

Which alignments and options should be supported for the post-content block?

[MichaelArestad]

Yes, we cannot use rich text here. We can support block-level color tools and font-sizes, though.

What is the reasoning here? Is this a temporary limitation?

[noahtallen]

What is the reasoning here

Rich text stores hardcoded HTML entities inline. So the content of the site title might look like <b>Here is my <i>title!</i></b>. This works fine when rendered in HTML, but the site title is used in a lot of other places. Anything that tries to access the site title would now need to understand and know about those HTML entities, which would be a breaking change. Theoretically, it's possible for anyone to handle the situation by stripping out all the HTML entities after we access the site title, but you'd have to do that everywhere you access it. (Which means it would break 3rd party code.)

One way around it might be to wrap the entire site title in bold or italics. So the content of the site title is Here is my title!, and the site title block allows you to say that the whole thing is bold or italics, and then it render <b><i>Here is my title</i></b> without actually storing those HTML entities in the database. (in the same way the other block-level attributes work.)

[Copons]

Just FYI I've updated the issue:

• Checked "Site Title → Heading"; as far as I can see there are no outstanding features left to update.
• Added #23788 to "Site Tagline → Paragraph".

Should we add the experimental colors, font size, line height to all FSE blocks?
(Colors might not make sense everywhere though, or might be more involved than just add a support property, e.g. for "linked elements", like the Post Title or Comment Count)

[MichaelArestad]

Should we add the experimental colors, font size, line height to all FSE blocks?

It makes sense for a few blocks like Site Title, Description, tags, categories, etc. Blocks that a user won't have design control of elsewhere.

[Copons]

With the merge of #24091 we've checked all items for this tracking issue! 🎉
FSE blocks should, can, and will be updated and improved over time, but I'm going to close this issue for now, since the basic requiremens are all complete.
Thanks y'all for the great work!

[mtias]

Thanks!