-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP/Try: Make pullquote a variation #8821
Conversation
If we go this way, we need a way to deprecate a block in favor of another one. |
Not suggesting the following, merely brainstorming: what if we simply removed it? Any existing pullquote would show up as — a classic block? A broken block? I seem to recall there being a ticket to handle this situation better? |
For now, they would show up as a classic block. |
In my deeply personal and non-official opinion, that would be fine, as you should be able to convert to blocks. Only, I just tried, and for some reason that doesn't work, it just remains a classic block. Hmm. I wonder if that's relate to #5946 |
💯💯💯 The pullquote/quote conflict has so much potential to be confusing to users (Why are the alignments different? Why does a pullquote use an attribution? What's the difference between the two? Why do they both use the same icon?) that I think it really makes sense to combine them like this, even if we lose out on a little bit of functionality for the time being. Pullquotes are great in a print setting, but they're kind of weird on the web, particularly in a mobile context.
Stylistically, I could see there being as much argument for floating blockquotes as for pullquotes, especially when (assumption) the majority of users likely won't know the difference between the two, from a semantic and stylistic perspective. Block alignment on text blocks can also be a bit confusing, because the text remains centred regardless of how the block alignment is set—ideally you'd be able to set both block-level alignment (on the container) and text-level alignment on the text itself. The benefits of collapsing these two blocks into one (reducing user confusion) should outweigh the potential sadface of losing that functionality here, especially if we have a way of re-introducing that functionality in a future iteration. |
This is awesome, thanks for getting the ball rolling on this, @jasmussen! 🎉 I'd also really like to see floating options on block quotes — that's a super common use case and I like that it could apply to all quote types, not just pullquotes. I recognise that might not be possible in this PR but I think it's worth getting in shortly after this lands. Only other point would be maybe name the new quote option "Fancy" instead of "Elaborate"? Fancy would be a touch more playful and humane. |
I don't know why the Pullquote has block alignment options, but if I had to guess, it is because pullquotes are often shown to the side or made wider than the rest of the post to make them stand out. Now, technically, the Pullquote block should have used an So I do not think the Quote block itself needs block alignment options, since wrapping it in a Container block could provide the same functionality and also make more sense semantically for pullquotes. And yeah, I think I prefer "Fancy" to "Elaborate". |
Incoming question ignorant of technical realities of block implementation: Could an |
It could, and that might make sense if this was indeed a separate block. But it can't be done if the pullquote style is just a variation. |
Given that you could accomplish the same thing as a dedicated Pullquote block by simply using a Quote block nested in a Container block, I see no reason to have a Pullquote block. Additionally, you could make that Quote-in-a-Container into a Reusable block that you could insert as a template. See also: #8403. |
It seems highly unlikely a Container block will land in 5.0, so perhaps applying float controls to the block could be a good temporary solution? That said, it's not possible to float quotes in Core right now, so maybe it's okay that doesn't land until later. (Could always be added as a 3rd party block or via a custom CSS class.) |
It seems like a bad solution to me if it involves knowingly adding a feature only to remove it a major update later, which could adversely affect websites where the feature is used.
Agreed, though I would really prefer if even a barebones Container block made it into WordPress 5.0. As it turns out, the Atomic Blocks plugin has a Container block which is pretty nice, though it lacks the HTML element switcher that would be necessary for a semantically correct pullquote, and it also does not have float alignment options. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design wise approving 👍
@noisysocks #6054 was reverted by #6501. A second attempt at making the Quote block use nested blocks exists in #6520. |
a720802
to
4d77f1e
Compare
This PR takes a meager stab at #5947 by copying the pullquote styles to the basic quote block and making it a variation, now titled "Elaborate". Name aside, which is up for discussion, this PR is mostly intended to get the ball rolling on eventually doing this, vs. keeping the status quo. If we mean to move forward, aside from feedback, the actual pullquote needs to be deprecated and removed, and I'd need help doing that as I assume it's not enough to just delete the pullquote folder. One issue already surfaced from this: the pullquote block features block level alignments, whereas the quote block features only inline level alignments (text align). That means you can float the pullquote, but not the quote. At least not yet, though presumably with a container block you'd be able to do that in the future. What are your thoughts on how to move forward with this?
4d77f1e
to
495ccc8
Compare
Okay, I gave this a rebase and a good squash, and I'm now calling the variation "fancy" instead. I also, in a separete commit so we can revert it, tried simply removing the pullquote block entirely. Which now results in this: Which I think is utterly fine. I think that's completely okay deprecation policy. However, there's an issue with converting the classic block to blocks — it simply doesn't work. So to answer your question, @noisysocks,
Yes! But I don't know why the block conversion doesn't work. Do you have any insights? |
@jasmussen It looks like the issue is the HTML comments. If you remove the HTML comments from inside the Classic block, it will transform just fine into a Quote block. |
Also, it looks like Quote blocks are missing the border they are supposed to have on the left in the Regular style variation. |
Yes, that definitely looks like a bug. I suspect we might be able to address it as part of #7811? cc. @brandonpayton It looks like it's because |
When we deprecated the Text Columns block, we left it in place so existing instances could be edited but removed it from being insertable. This seemed like a nice, gentle way to do it, though there unfortunately isn't a user-facing deprecation notice, just a console warning. Today, (as others have said) an unregistered block will be converted to the classic block. If we land #8274, users will see a notice about the unregistered block with an invitation to leave it as-is, remove it, or convert to HTML. Once converted to a Custom HTML block, converting the pullquote html to blocks, results in the creation of a quote block with the right quotation but missing the citation. In a future iteration of the unregistered block warning, it would be nice to allow users to convert to other block types that support transforming from the unregistered type. I hope this helps. |
@brandonpayton Notably, I added user-facing deprecation notices for the Pullquote block via the title and description. See #9358. I could make a PR doing the same for the Pullquote block, but I can not really provide a good recommendation in the description for what block to use instead, nor can I add a semantically correct transform. A semantically correct pullquote uses a As it is, I think the pullquote is in a weird sort of state where it is the only way (ignoring the Custom HTML and Classic blocks) to create a semantically correct pullquote... except that it does not even do that (it does not currently use an |
Taking a step back a bit here. I don't think Pullquotes should be represented as style variations of Quote. They are not the same entity. They have semantic value (even if the markup doesn't show it now) and a specific meaning separate from regular quotes. The fact Pullquotes have extra block alignments (wide, full-width, left and right) should already indicate that they are different blocks. It doesn't make sense for Quote to absorb this complexity. To me this is a perfect example of something that becomes simpler if it's a separate block. I do agree that Pullquote should be updated to be wrapped with an Edit: We could include color options for blockquotes, for example, which would be a bit overkill for Quote. |
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?
One implication that resonates with me from your comment, Matías, is that it's every easy for us to be blindsided by the fact that using containers and child blocks we can accomplish the same with individual blocks. This does not necessarily mean we should, especially at the cost of overloading the variation interface. Sometimes a dedicated block might be the better option. For that reason I took a new stab in #9599, and closing this one. |
Yes, exactly. Also, even if similar shapes can be achieved with containers, it might not be the most intuitive to the user, and we might also lose a bit of semantic clarity. I now see Pullquote in a similar way to the Half-Media block that is being worked on. |
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?
Squashed commits: [10feb74] Added deprecation artifacts [d71a0cc] Fix for frontend. [680c767] Figure. [efdc070] Add aside wrapper to pullquote 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?
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?
* Add aside wrapper to pullquote 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? * Figure. * Fix for frontend. * Added deprecation artifacts * Updated test fixtures
This PR takes a meager stab at #5947 by copying the pullquote styles to the basic quote block and making it a variation, now titled "Elaborate". Name aside, which is up for discussion, this PR is mostly intended to get the ball rolling on eventually doing this, vs. keeping the status quo.
If we mean to move forward, aside from feedback, the actual pullquote needs to be deprecated and removed, and I'd need help doing that as I assume it's not enough to just delete the pullquote folder.
One issue already surfaced from this: the pullquote block features block level alignments, whereas the quote block features only inline level alignments (text align). That means you can float the pullquote, but not the quote. At least not yet, though presumably with a container block you'd be able to do that in the future.
What are your thoughts on how to move forward with this?
What you can do with the current pullquote block, but not in the variation:
Here's how the new variation looks: