Add aside wrapper to pullquote

[jasmussen]

This is an alternative, per discussion, to #8821.

It adds some semantic value to the pullquote, indicating that it is intended to be separate content.

Note that we should consider doing a few other enhancements to the pullquote, if we intend to keep it:

• Let's add a transformation from Quote to Pullquote and back
• For some reason, the alignment values are not output in the markup in the editor, only on the frontend, which means the max-width we apply does not affect the content.

I could use help with both of these. I also imagine the deprecation handler needs a little extra now. @gziolo do you have bandwidth?

Screenshot showing the max width not being applied (note, this is not a new regression, this is in 3.7):

[afercia]

Sorry but the <aside> usage here is arguable. I've read the discussion on #8821 but it's based on a wrong assumption. Although one of the examples in the HTML specification is a pullquote, the <aside> element has an intrinsic role of cpmplementary and as such it's considered a landmark role.

We should definitely avoid a pullquote is listed and announced as a landmark region by assistive technologies. In the editor, there should be just the main landmark regions defined by Gutenberg.

In the front-end, the usage of an <aside> element is more appropriate for sections of content, not for a single pullquote. From the spec:

https://www.w3.org/TR/html52/sections.html#the-aside-element

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

Assistive Technology may convey the semantics of the aside to users. This information can provide a hint to users as to the type of content. For example the role of the element, which in this case is "complementary", can be announced by screen reader software when a user navigates to an aside element. User Agents may also provide methods to navigate to aside elements.

Note the same issue as discussed time ago for the core widgets (can't find the Trac ticket right now), as in some themes each widget in a sidebar uses an <aside> element, which is simply wrong.

[mtias]

I think in this case a "figure" might be more semantic given the intention.

[afercia]

Whatever, as long as it's not an aside 🙂
Worth reminding semantics is not perceived directly by humans. It is by software and, through software, by humans that use that software. To my knowledge, screen readers are basically the only software that communicate semantics to users.

[afercia]

Thanks for the change. I wonder why <figure> is used on the editor and not in the front-end though. I'd say it should either be removed in the editor or added in the front-end?

Just to document what was happening with the <aside> element, see in the screenshot below 2 pullquotes listed as complementary regions in the available landmarks:

[mtias]

Should be added to front-end too, yes.

[aduth]

Noting that we might need to account for migration if this would invalidate previously-saved pullquote blocks.

[jasmussen]

Noting that we might need to account for migration if this would invalidate previously-saved pullquote blocks.

Great point. This is what happens now; this is a pullquote created in master:

This is what I saw when checking out this branch on the same post:

This is what happens when I pressed "Convert to blocks":

So looks like citation is lost, but I feel like that's tracked somewhere?

Would appreciate input on how to provide a migration path if anyone has time.

[ZebulanStanphill]

@jasmussen You could just use the deprecated block API in this case. The Paragraph block has some examples of using it.

https://wordpress.org/gutenberg/handbook/block-api/deprecated-blocks/

[jorgefilipecosta]

I rebased this PR, and had a final look at it. I think the changes look good 👍

[ZebulanStanphill]

Just for reference:

A figure element’s contents are part of the surrounding flow. If the purpose of the page is to display the figure, for example a photograph on an image sharing site, the figure and figcaption elements can be used to explicitly provide a caption for that figure. For content that is only tangentially related, or that serves a separate purpose than the surrounding flow, the aside element should be used (and can itself wrap a figure). For example, a pull quote that repeats content from an article would be more appropriate in an aside than in a figure, because it isn’t part of the content, it’s a repetition of the content for the purposes of enticing readers or highlighting key topics.

https://www.w3.org/TR/html52/grouping-content.html#the-figure-element

So we are definitely going against the spec on this. That said, I understand the reasoning, so I am fine with using a <figure> instead. It is more semantically correct than a <div> or no wrapper.

[aduth]

Minor: Spread operator is not necessary here (and has a small performance cost), vs. just assigning directly as attributes: blockAttributes

[ZebulanStanphill]

If the blockAttributes variable was just called attributes, you could make it even shorter:
attributes,

[aduth]

The demo content should have been updated here. While the deprecation migration saves it from being flagged as invalid, it does cause the demo post to trigger an autosave after delay.

Block validation: Block validation failed for `core/pullquote` ({name: "core/pullquote", title: "Pullquote", description: "Highlight a quote from your post or page by displaying it as a graphic element.", icon: {…}, category: "formatting", …}).

Expected:

<figure class="wp-block-pullquote"><blockquote><p>Code is Poetry</p><cite>The WordPress community</cite></blockquote></figure>

Actual:

<blockquote class="wp-block-pullquote"><p>Code is Poetry</p><cite>The WordPress community</cite></blockquote>