Quote: use nested blocks

[ellatrix]

Both quote blocks can take advantage of nested blocks. This is necessary to allow blocks other than paragraphs inside the quote content, e.g. a list or a heading. It would also enable us to simplify RichText down the road.

I've implemented this before in #6520, but it was closed because the nested blocks UI didn't seem good enough at the time (cc @jasmussen to check if it is now), and the PR has gotten too old to rebase. I suspect a lot of things can reused from it.

[jasmussen]

The UI is not yet ready, sadly. But both @kjellr and I consider it among our top priorities to get this right, and we have two or three promising ideas and are working through prototypes. We'll be sure to share updates as soon as we can.

[mapk]

I'm still uncertain if the UI is ready at this point. I know there are efforts to redesign the block UI, so this could drastically change soon.

BUT, nested blocks should be similarly configured throughout the whole of Gutenberg regardless of block. Should we move forward with a new PR and make design iterations there? And when the block UI is updated, it should also take into account nested blocks and proactively make the necessary adjustments.

If we limit the blocks that can exist in the Quote block, should any more be added other than these?

• Paragraph block
• Heading block
• List block

[jasmussen]

I know there are efforts to redesign the block UI, so this could drastically change soon.

You're referring to efforts explored in #18667. And I agree — those UI changes combined with the breadcrumb bar and the select tool should be key to unlocking nested UI for quotes.

But some of the changes Ella have been working on with minimizing the amount of HTML nodes in the DOM will also help. The thing is, right now as soon as a block containser inner blocks, there is an explosion of extra HTML elements that need to be carefully positioned so as to look right. The lighter UI from Ella, will mitigate that. But additionally, blocks currently have margins and negative margins so as to show the "block is being edited" border 14px outside of the block footprint. The new UI explores a different take on this that emphasizes focus instead, and eliminating those margins altogether. That could go a long way in making sure we don't have to write crazy CSS hacks to make a quote with nesting look right.

[mtias]

I think we are ready to give this another go (with the "absorb toolbar in parent").

[ellatrix]

Yes, I think we should try this again, now that we both have the breadcrumbs in the toolbar and have the option to absorb the toolbar in the parent toolbar. It's time for us to try these on the quote block so these interactions can be tested more in different situations, which will push for polish and benefit the other blocks too.

Using inner block for quote would also resolve a number of issues. It would allow quotes to contain other blocks like images and lists, and prevent content to be lost on paste or converting to blocks. Doing this is essential to increasing confidence in raw handling of legacy content.

[jasmussen]

Interestingly, with the draggable handle in the block toolbar having recently improved, it seems like the utility of the "absorb toolbar in parent" features now feels most appropriate for very narrow contexts like buttons, navigation and social links. For Quote, it might just make the drag and drop experience worse (GIF in #23020 (comment)).

[ellatrix]

Yeah, I think the "Select parent" button that is added to the toolbar will have to do. :) Maybe we can also leave the citation field open if child blocks are selected, so when you click on it, you also select the parent (in other words, makes the clickable area of the quote itself bigger).

[jasmussen]

Maybe we can also leave the citation field open if child blocks are selected, so when you click on it, you also select the parent (in other words, makes the clickable area of the quote itself bigger).

Seems worth trying.

[enriquesanchez]

Here's a little prototype that goes over how the flow for nested blocks in the Quote block could work. It follows the same pattern we already use on other blocks that support child blocks, like the Group block.

I think that we'd want to limit the type of blocks that can be added inside the Quote block. On the prototype, I'm proposing to have the citation field be its own block. This should allow authors to create richer content inside the Quote block.

We could start with a short list of allowed blocks and slowly grow from there:

• Paragraph
• Citation
• List
• Headings
• Code

In short, the Quote block would behave like and have similar properties as other containig blocks:

---

@jasmussen Is this in line with what you had in mind before?

[ZebulanStanphill]

Worth noting that the most "semantically-correct" way to show a blockquote citation is to wrap it in a <footer> at the end of the blockquote, e.g.:

<blockquote>
<p>A paragraph</p>
<p>And another</p>
<footer><cite>Zebulan</cite></footer>
</blockquote>

This also helps a bit with styling, since technically it's valid to use <cite>s inside a blockquote and have them not be the quote's citation. (See the first example usage in the WHATWG HTML spec and HTML 5.2 spec.) Some themes style any <cite> inside a <blockquote> the same way, which can look a bit weird when trying to use <cite> in other ways within the <blockquote>.

[jasmussen]

Nice prototype! Thank you for the ping.

I think that we'd want to limit the type of blocks that can be added inside the Quote block. On the prototype, I'm proposing to have the citation field be its own block. This should allow authors to create richer content inside the Quote block.

If the citation field becomes a block on its own, then you'll need to know of its existance to add one, even if a pattern can pre-insert it for you. Whereas if it's not a block, but more of a field that pops out just like a caption on an image, it's more easily discoverable and we can ensure proper footer markup (no moving the footer to the top of the block).

Perhaps we can ensure the citation field is visible both if the quote container and a child block is selected? There was also Ella's idea:

Maybe we can also leave the citation field open if child blocks are selected, so when you click on it, you also select the parent (in other words, makes the clickable area of the quote itself bigger).

That seems worth trying.

As for limiting the blocks inside, if we do that we should mimic what's allowed in the spec. As I see it the primary use case for adding nesting to the Quote block is to be able to multi select a bunch of blocks and transform it to a quote. That needs to be able to at least accommodate an image block, or it's going to frustrate.

It's definitely good to move slowly and add features when we know they are needed, but in this case I see the Quote block more as an opinionated version of the Group block in behavior.

[KokkieH]

We could start with a short list of allowed blocks and slowly grow from there:

Could the quote block also be included in this list? In other words, make it possible to have a quote inside a quote?

Use case: Someone quoting an academic text, where the quoted text itself also contains a quote.

Requested in https://wordpress.com/forums/topic/quoting-multiple-paragraphs/

[jasmussen]

Could the quote block also be included in this list? In other words, make it possible to have a quote inside a quote?

I think absolutely yes. In general I would say that if it's allowed in HTML, it should be possible in Gutenberg, otherwise some classic block transformations will break.

[ZebulanStanphill]

The output varies from theme to theme. Some may use ::before pseudo-elements to add a dash, and some might not.

[mtias]

Slightly unrelated to this task, but we can consider the citation to be an action you add from the toolbar "Add citation" so that it's not present by default.

[enriquesanchez]

What if we made this placeholder closer to the output?

@kellychoffman You're right, the citation field should be styled depeding on the theme. It was an oversight in my mockups, but it should've looked like this:

Is this what you had in mind?

[enriquesanchez]

we can consider the citation to be an action you add from the toolbar "Add citation" so that it's not present by default.

@mtias That's an interesting idea, I like that it's somewhere in-between my suggestion of having the citation field be its own block and the current pattern. Basically, the citation will be optional but when used it'll show up semantically correct because we would still be rendering it at the end of the blockquote, as @ZebulanStanphill pointed.

Something like this:

A couple of thoughts:

1. If the citation is left empty after adding it from the toolbar, we should still hide it. This is what we currently do.
2. While I like the feather pen icon I'm using in the mockups, it's the one we currently use for the verse block and we'll need to explore other ideas. Suggestions are welcome.

[kellychoffman]

Is this what you had in mind?

Not sure this is working, particularly the copy of Write citation. I do like the simplicity of the - in the latest mock.

[carolinan]

It doesn't look to me like there is enough time for this update to be ready within a reasonable time frame for it to be tested with the default theme.

[jasmussen]

Even if this feature doesn't land in 5.6, it will land in a plugin release. And while that's definitely a different support cycle, it would be nice if it didn't look horrendously bad in the default theme.

[mtias]

This one needs a little bit more work before we are confident the tradeoffs it brings are worthwhile. Let's remove it from the 5.6 milestones.

[estelaris]

What type of work is still needed? We discussed today in design triage but are uncertain on how to proceed.

[jasmussen]

What type of work is still needed?

The citation field is the missing piece. And the easiest next step is to keep the design and behavior for the quote block intact. I would like to work on the PR to make it happen, I believe @nosolosw has one open. Specifically I believe I can output the citation field whether the parent or a child block is selected, making the behavior for the citation the same as it is today. Andrés feel free to ping me if you'd like to work on this.

Separately, but not necessary to keep this ticket open for, general work to improve how to select the parent block will benefit. And we can also, depending on the user experience of the easy solution outlined above, explore putting a button in the toolbar to add the sitation field after the fact. Could be as simple as a text label "Add citation" button on the Quote block. This is more work, though, so should be a separate exploration, probably.

[oandregal]

👋 I had #25892 there was some discussion about how the cite should work with inner blocks. I can look at that this week. Thanks for your patience here, I found my queue on fire coming back from AFK the past week 😅

[mtias]

This is more work, though, so should be a separate exploration, probably.

The only caveat is that not having a specific button to add the citation could make the implementation with inner blocks a lot more complicated, including keyboard navigation, so if we can avoid that it'd make sense to do the final solution from the start.

[jasmussen]

Took #25892 for a quick spin, and outside of a focus issue, the citation feature already behaves identically to its non-nested counterpart:

Since that's the case, I think it's fine to keep that as is, for this PR, in order to ship the benefit of quotes with nesting.

However if there are unforeseen consequences in fixing up that PR, or if we find the following to work better, we could just add this button to the quote block toolbar:

Clicking that one would reveal the citation field at the bottom of the quote.

Both feel like they could work.

[hedgefield]

Looks good to me! Does that leave any loose ends for this issue or is it ready to wrap up for 5.7?

[mtias]

There are some loose ends — selecting the Quote is now harder — but the issue can be closed once #25892 is merged.