Gutenberg: Quote: use nested blocks

Created on 7 May 2019  Â·  24Comments  Â·  Source: WordPress/gutenberg

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.

Needs Design Feedback [Block] Pullquote [Block] Quote [Status] In Progress [Type] Enhancement

All 24 comments

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.

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

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.

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

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.

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 https://github.com/WordPress/gutenberg/pull/23020#issuecomment-641834552).

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).

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.

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.

2020-10-02 15-58-14 2020-10-02 16_05_24

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:

Screen Shot 2020-10-02 at 16 06 06


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

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>.

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.

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/

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.

Great feedback everyone, thank you!

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).

That's a good point and I agree, @jasmussen. Here's an updated mockup reflecting this idea:

Prototype

Notice how after adding the Quote block, we default to a Paragraph block waiting for text input and the block breacumbs at the bottom show that Paragraph is nested under Quote.

Also as suggested by @ellatrix, the citation field is open and part of the containing Quote block.

Users can then start typing, or add any other allowed type of block (even a Quote block, as suggested by @KokkieH). In the following mockup, a user has added a Paragraph and immediately after that a List:

Prototype-2

Notice how the block breadcrumbs now reflect this structure.

As with other containing blocks, selecting the parent block sets a selection border all around the contents:

Prototype-3


How does this feel?

Worth a shot!

Write citation

What if we made this placeholder closer to the output? ie. – Citation or – Author or – Quote author

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

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.

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:

Prototype

Is this what you had in mind?

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:

2020-10-09 16-49-01 2020-10-09 16_50_11

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.

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.

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.

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

maddisondesigns picture maddisondesigns  Â·  3Comments

mhenrylucero picture mhenrylucero  Â·  3Comments

aaronjorbin picture aaronjorbin  Â·  3Comments

maddisondesigns picture maddisondesigns  Â·  3Comments

spocke picture spocke  Â·  3Comments