Having two types of quote is confusing

[sarahmonster]

We have two different quotes available: a quote and a pullquote. Technically, the idea is that a quote is something someone else said, and a pullquote is a piece of text from the text of your article, pulled out to give it emphasis as a graphic element.

Our descriptions do indicate this difference—the pullquote is described as "Give special visual emphasis to a quote from your text."—but then we undercut that a bit by offering a citation for the quote, which isn't generally used with a pullquote. From a user perspective, this makes it seem as though both blocks are used for the same purpose, but offer slightly different styling. But then each block also has style variations—so there's lots of potential here for user confusion.

There's also a semantic difference between the two, where a quote is a <blockquote> element and a pullquote is an <figure> element, but that is largely invisible to the majority of users.

It's also been identified as a point of confusion in usability testing: https://make.wordpress.org/test/2017/12/06/wcus-gutenberg-testing-volunteer-feedback/ and it threw me off as well when I first tested these blocks myself.

This has come up in earlier issues (#5947), but it might be worth revisiting for 5.0 in order to reduce unnecessary user confusion.

Pullquotes work really nicely in print, where layouts are fixed, but they make less sense on the web, where people are increasingly reading on mobile devices and duplicating content is a bit weird. There are also accessibility concerns if people are using pullquote for its intended purpose, and duplicating their content. (I think we'd want to add an role="presentation" aria-hidden="true" to the containing <figure>, but @tofumatt may know better there.)

My recommendation would be to remove or hide the pullquote block for now, since its functionality can eventually be replicated by a container block and a nested quote, and it introduces needless confusion for the majority of users.

Failing that, we should at least remove the citation from the pullquote block. Since the intention of a pullquote is to quote from the article itself, a citation doesn't make sense in this context. We may also want to consider the accessibility implications of pullquotes being used for their intended purpose.

[colorful-tones]

I agree with all the observations above.

I would speculate that the existence of both the Pullquote and the Quote likely stem from a handful of requests to allow for more customization of quotes (in general sense). Whereas, the Quote block existed first, and then there was perceived enough customization requests so that the Pullquote was then created to address. Again, total speculation, but worth stating (in my opinion). 🙈 🙉

The biggest difference between the two blocks (besides the semantic HTML output noted by @sarahmonster) are their customization options.

The Quote block just has one Style option: "Regular" or "Large"

Whereas the Pullquote has multiple options: Style: "Regular" or "Solid Color" and Color Settings: "Main Color" (color picker) and "Text Color"

The existence of the Pullquote block is confusing. However, both the Quote and Pullquote block's options offer quote (in general sense of term) affordances, which should likely be merged. So that, the Pullquote should be removed, but the setting options ("Main Color", "Text Color") could be merged into the Quote block. So that the Quote block would have all of these options:

• Text Settings: Font Size: Normal, Medium, Large, Huge / Specific Value (similar to current Paragraph block)
• Style: Regular or Solid Color
• Color Settings: Main Color and Text Color

However, I think these settings should be prioritized for 5.0 release. So that the simpler the better. I would remove Pullquote, leave Quote options as is, and incorporate Pullquote's options in to Quote as phase 2.

[karmatosed]

I have seen the pullquote used a fair bit, which makes me wonder if a style makes sense. I don't see a case for removing pullquote in 5.0 as that time has also passed right now, however let's think about iteration.

[Presskopp]

The whole concept about quotes is confusing and even useless. What is the (special) empasis the block help text is talking about? Making it italic? The preview does not work for me and I could make a long list of things I don't like about it.

The 'italic' button does nothing in quotes - confusing. A quote can't be non-italic? Where are the quotation marks? What's so special in special visual emphasis of a pullquote, I/we don't have a clue how to translate the help texts for german in a meaningful, helping way etc, etc.

[mcsf]

What is the (special) empasis the block help text is talking about? Making it italic?

The first thing about quotes is document semantics. Internally, a quote uses HTML's blockquote tag, and optionally the cite tag, as it should. Externally, this means that most users will see something that looks like a quote, but it also means that users that use assistive technologies (a11y) will still be informed that a particular piece of content is a quote. Internally, it means that a content creator can specify their intent by way of choosing the Quote block, and from that intent Gutenberg will provide a specific experimence for quotes. Finally, a proper semantic document is nicer for machines to parse and thus contributes to better Search-Engine Optimisation (SEO).

Perhaps the mistake was in using "emphasis" (and "visual"?) in the copy. /cc @alexislloyd @mtias

The preview does not work for me and I could make a long list of things I don't like about it.

This sounds like a separate issue.

The 'italic' button does nothing in quotes - confusing. A quote can't be non-italic?

A quote can be rendered in any way, but this is up for the theme to decide. If the theme doesn't have an opinion, then the Quote block provides default styles which happen to use italics.

Where are the quotation marks?

These can be introduced by the theme via CSS (typically using the ::before or ::after pseudo-elements).

What's so special in special visual emphasis of a pullquote, I/we don't have a clue how to translate the help texts for german in a meaningful, helping way etc, etc.

It seems like the focus of confusion here is the fact a distinction is made between Quote and Pull quote, correct? That, I agree, is worth debating, and indeed is the subject of this issue.

[timwright12]

I don't think either item should be removed from the UI as they both have a semantic and editorial purpose and if they're combined into the same block we're likely to see a higher level of misuse in the editorial output leaning towards whatever the default state is.

From an HTML standpoint, using a figure element as a pull quote wrapper seems to align with the specification:

The figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

However, I don't think nesting a blockquote is correct, which is why the citation is coming through. Everything I've researched so far has not contained a nested blockquote/citation, but rather just paragraph text. This would be more like an optional caption situation rather than a normal citation.

Adding role="presentation" and aria-hidden="true" to the wrapping element feels a little heavy handed to me since aria-hidden will remove it from screen readers without setting the role.

I'm torn on this one, because If something is represented visually, unless it is purely for presentation it should be communicated to screen readers and I do believe there's editorial value in a pull quote, or they wouldn't be used.

I would lean towards one of these as a solution/action item for this ticket:
Option 1: Make the pull quote more visible

<figure role="region" aria-label="Pull Quote">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

Option 2: Make the pull quote less visible

<figure aria-hidden="true">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

Both options also remove the nested blockquote. Personally, I do think there is value in presenting pull quotes to assistive technology, the same way there's value in using it for a sighted user; so I would lean towards Option 1 rather than removing the content. But I would love to hear other thoughts @sarahmonster @colorful-tones @mcsf @tofumatt

[mcsf]

Thanks for your comment, @timwright12. Between the two, I'd also lean towards option 1: keep things visible and be more explicit about the nature of the element for screen readers.

However, I'm not sure we should drop blockquote from the figure. Can you expand on that?

[timwright12]

Since a pull quote is unlike a blockquote, where the content is jus something repeated from another part of the article (and can be removed without affecting the content flow), the figure element and optional figcation communicate the correct semantics rather than using a blockquote, which is for someone other than the author of the article, and needs a citation.

[mcsf]

That's a good point and a way to clearly distinguish Pullquote from Quote. I'll let others weigh in.

[colorful-tones]

Pull Quotes are an artifact of the print era and will likely only be used by a small, niche group. Which leaves the majority of non-technical editors and users who do not necessarily care about semantics and will just default to using the Quote block, because they need a quote. Unless, they're feeling adventurous and realize that the Pull Quote has more customization options, and will then exploit it for those features with disregard for semantics.

Really, all that 👆 is pure speculation and user persona assumptions, which can only be solved with some solid user testing to see some metrics on what people are using them for, and why.

Further reading up on the concept of Pull Quotes produces some interesting nuances:

Make pull quotes stand apart from the accompanying text. Set the pull quote apart by using a different typeface, setting it off by rules or in a shaded box. Try using oversized quotation marks or aligning it to the right or having it cross two columns of text.

-- Jacci Howard Bear. "How To Use Pull-quotes to Add Visual Flare to Articles". Updated February 11, 2019. Lifewire.com

Or

TIP: Pull-quotes should grab the reader’s attention, not play tug-o’-war with it. Limit pull-quotes to one to a page to keep your layout from becoming too busy.

-- Ilene Strizver. "Pull-quotes". www.fonts.com. Archived from the original on 17 July 2010. Retrieved 2012-07-09.

Or

A disadvantage of pull quotes as a design element is that they can disrupt the reading process of readers invested in reading the text sequentially by drawing attention to ghost fragments out of context. At the other extreme, when pull quotes are used to break up what would otherwise be a formless wall of text, pull quote can serve as visual landmarks to help the reader maintain a sense of sequence and place.

-- Wikipedia contributors. (2018, June 18). Pull quote. In Wikipedia, The Free Encyclopedia. Retrieved 14:11, February 12, 2019, from https://en.wikipedia.org/w/index.php?title=Pull_quote&oldid=846430528

So, it seems the context of pull quote usage is quite important. Visual impact can serve as either a hindrance or promotion of the contained text. There is also SEO implications to consider: duplicate content.

Since Pull Quotes exist in Gutenberg and are not likely to go away. It does seem best to leverage <figure> to capture the semantic meaning. I too am on the fence though about how and whether we should be highlighting the content for screen reading technologies.

If we're highlighting the quoted text to merely provide a visual relief from a "formless wall of text". Then I might lean more towards @timwright12 's Option 2:

<figure aria-hidden="true">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

But I do not want to be exclusionary and I do not use screen reading technology in my every day experience with the web.

[mcsf]

Thanks for the comprehensive reply.

I am sure Pull Quotes will be used in many different ways. Although in its original print form it meant to repeat text from the body, we can't guarantee that, nor impose it on users. For that reason, I'm reticent about making Pull Quotes invisible to screen-reading devices. I wouldn't oppose to making that an advanced block option, though. Thoughts, @sarahmonster and @karmatosed?

[afercia]

Removing the accessibility label, as it's not strictly related.

[karmatosed]

I still feel that if we have a more than one quote, it should be a style. I can see a path where someone looks for 'quote' and applies 'pullquote' as a style variant.

[mapk]

I'm all for keeping both the Pullquote block and the Quote block based on @timwright12's comment above. I agree that we should remove both the blockquote and the citation from being nested in the pullquote. And if there's still value for sight-impaired users, then Tim's option 1 makes sense.

Option 1

<figure role="region" aria-label="Pull Quote">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

Let's go this route for now.

[campaignupgrade]

@colorful-tones analysis looks correct; a quote is for where a passage or speaker is being cited verbatim. A pull quote is a duplicate of text found elsewhere in the content but displayed in a graphical fashion.

However there is an issue with the <figure> tag. Google will index the <figure> tag as part of the article because a <figure> is content that is considered supplementary or at least tangentially related to the primary content, such as a chart, graph, or image. Duplicating content may have a negative effect on SEO.

On the other hand an <aside> is considered non-content for indexing purposes and will be ignored. Though Google officially suggests <aside> tags will be treated as tangential content, testing has shown that Google generally ignores<aside> content.

The HTML spec supports <aside> as the wrapper for pull quotes:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

[carolinan]

With the update of the quote block to use inner blocks and with added block supports for styling, I think it is time to reconsider deprecating or at least hiding the pull quote block in the inserter.

[carolinan]

I still feel that this pullquote block should be deprecated, perhaps I am having an off day but there are 30 Trac tickets with reports about bugs with the bundled themes and this block.

https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&summary=~pullquote&order=priority

[mtias]

@carolinan yeah, I think it's a fine time to deprecate.

[karmatosed]

I fully support deprecating but would love to get a plan worked out as we do this, so thank you for raising this @carolinan and getting agreement @mtias. The plan itself would be what if any impact default themes would have around this. There has been a fair bit of patching up around those themes so far and ideally we need to review if:

• The merging fixes all of those issues.
• Fix ones it doesn't.

I am excited about doing that because it could move on quite a few issues at once along with this there is the opportunity for some styling clean up we should ticket for within those themes.

[carolinan]

@t-hamano Do you want to work on this? If not I might try to use your post-author deprecation as an example.

[carolinan]

we need to review if:

• The merging fixes all of those issues.
• Fix ones it doesn't.

Deprecating the pullquote would not fix existing issues, converting each block in the content is a manual process.
But we can decide to give those issues a lower priority.

[t-hamano]

It seems that the addition of the Pullquote block was proposed in #547. That was 7 years ago, and it seems that the main purpose was to embellish the Quote block.

Now, the Quote block has almost the same block support as the Pullquote block, so I agree with deprecating the Pullquote block.

The big difference between the two blocks is that the Quote block does not support wide/full width. If the Pullquote block is to be deprecated, I think we should add wide/full width support to the Quote block before that.

Also, to be clear here, deprecating a block generally means that we cannot insert it from the inserter. Deprecated blocks already inserted in content will not break, and styles will be preserved.

cc @aaronrobertshaw - Because I think this issue will be relevant to moving forward with #43241

[aaronrobertshaw]

Thanks for the ping 👍

Because I think this issue will be relevant to moving forward with #43241

It's a community effort to achieve more consistent design tooling across blocks. It will also take time and blocks will come and go. That shouldn't cause any issues though.

[mtias]

@t-hamano good call on supporting width alignments

[ramonjd]

+1 On deprecating the Pullquote block for reasons stated.

I think that the cite element has some semantic value for both <blockquote /> and inline text.

Maybe users could have the choice to apply it to any rich text?

I quickly added it to the formatting library to test:

Kapture.2024-07-26.at.11.51.21.mp4

Happy to get a PR up if folks think it's a worthy addition.

[carolinan]

Please open separate issues for the quote block, otherwise the suggestions will get lost more easily.

[t-hamano]

Is adding the cite element as inline formatting a prerequisite for deprecating the Pullquote block?

If not, I'd start by adding width support to the Quote block.

[ramonjd]

Is adding the cite element as inline formatting a prerequisite for deprecating the Pullquote block?

I don't think so. Feel free to go ahead 👍🏻

[t-hamano]

The following enhancements have been made to the Quote block:

• Add align support:Quote Block: Add align support #64188
• Add spacing support: Quote: Add spacing supports #63545

By now, the block support in the Pullquote block should be fully supported in the Quote block as well.

Are there any other things we need to do to deprecate the Pullquote block?