-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Unify the block toolbar for all text blocks #3785
Comments
🙂 |
I guess the question here, is whether it's necessary for the basic operation of the heading block? Opinions may defer here because we do not align heading so often. |
So SALTY :D I love it. I think those arguments are fine. Seems like it could be worth doing a quick experiment where we put every heading level in the Switcher, and remove the h2 h3 h4 quick shortcuts from the toolbar to make room for alignments. What do you think? |
😜 Both points make sense. However, I think the real point is we shouldn't sacrifice functionalities just because there's not enough space 🙂 That would be making function follow form, while I guess we'd agree it should be the opposite. |
No that's fine — but it's always going to be a balancing act. Do we put "Dropcap" there? Text color? At some point, and this is what Riad suggested, we have to decide whether the feature in question is basic or advanced. This would be the case even if we had an overflow menu for the quick toolbar. That doesn't mean we can't revisit or iterate, and it seems like it'd be easy to add all the heading types into the switcher as an easy way to accomodate the consistency it would be for the two most basic of text blocks to have the same quick toolbar. |
Yeah I agree. I see aligning headings as less frequent than aligning text (maybe). For example, right-aligned headings are pretty rare, but center-aligned headings are common. Yesterday we've run an user testing session during our Milano meetup, following the testing scripts used at WCUS. It was interesting seeing how even experienced users struggled with some basic tasks, and finding things in the sidebar was definitely one of those things. |
|
😬
😬 Good points, both. For example, headings in Twenty Seventeen use |
That is a good point, Norris. I think the suggestion detailed here is still worth exploring: making the "text" related toolbars all be the same, and putting all heading sizes in the switcher. Though i could swear @paaljoachim had opened a ticket with a similar idea. |
Throwing a +1 to alignment on headings in here. I just found I really wanted to do that in a design I was working on. Yes, we can do things in CSS but we're giving power to users here and we aren't giving it consistently. We should I feel after hitting this experience, offer alignment on all elements possible. |
This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs. |
I also recently got caught by inconsistent placement of text alignment buttons placement. I started using Gutenberg for writing and it is really frustrating when you go through paragraphs and headings and for first align is in the toolbar and for second in the block settings, were usually more specific customizations resides, so +1 from me to place headers aligning in the toolbar! |
Count me in 👍 Perhaps this PR can be considered: #5635 It seems we should also remove the alignment controls from the block inspector? If so, I'll update the PR. |
Just changing the title here so we can work on this as a unifying issue. This would need to move all the alignment into the switcher for this to work. Let's explore though. |
I took the liberty of updating the original ticket with the mockups from #5635 (comment). |
@talldan Notably, the block styles are currently only used for CSS styling changes via classes. Different heading levels use different HTML elements, so having the heading levels use block styles would involve changing the structure and semantics of the block. I am not sure if it is planned for the block styles API will support that in the future. One drawback to supporting structural changes is that a theme could add support for a variation that changes the structure of a block, but when you change themes all instances of the block with that variation would become invalid. As long as block styles are limited to adding CSS classes, no blocks will become invalid upon changing themes, and the unsupport styles will simply be shown as custom CSS classes in the block inspector. The styling will likely break, but the blocks will still be valid. |
I see, thanks for the details @SuperGeniusZeb. That makes total sense. The implication of themes breaking the backwards compatibility of a block is a tricky one. I had a quick idea for how we might solve it, but it might be a bit complex. Here's an example style for a heading:
We could validate style rules ahead of time because they're simply data, and not show them if they don't contain a valid value for an attribute. I think this would work for styles, since most of the time we want to keep them within our control (we know the values ahead of time). |
I am not convinced if we have the block chip that the header drop down won't confuse people now. We'd need to get feedback on that. Just seeing 2 H's is a little visually confusing. |
I tried again to format in italics two different blocks (a paragraph and a list). I had hoped, I could be able do this with the Unified Toolbar, as it’s always present on the top. As soon as I highlighted the two blocks, the toolbar disappeared. http://recordit.co/2v3Mslgl1p @jasmussen pointed me to this issue here. It seems to be related. The need to format text over multiple different blocks is certainly a basic function of an editor. And it's one I am missing the most when looking back to the old editor. I have to format paragraphs one at a time. |
Here's yet another updated mockup for the heading block, based on Zeb work in #3785 (comment): Question: what remains to be done after the heading block is updated? I'm not sure of the value of adding text alignments to the list block, so when the heading block is done, it feels like the spirit of this ticket has been addressed as best possible in this phase. @bph issue as noted in #3785 (comment) to me feels like a new issue, which is to enhance the multi-selection toolbar to be smarter about the contents it selects. Perhaps #6128 is a better ticket to discuss that? |
+1 to moving the Heading alignment buttons to the toolbar. |
@jasmussen can you make an issue with that mockup and close this one? The above is more actionable. |
This is what the current the paragraph block toolbar looks like. It should be added for all text blocks. Mobile version would then show the alignment options in a drop down. Additional thoughts. In the drop down arrow menu additional Rich text options can be added. Color (for single word), justify as well as other options. https://wordpress.org/plugins/advanced-rich-text-tools/ |
Sure thing! Let's get this show on the road. This is a good first step, and it does not preclude additional steps in the future: #15096 |
We should consider unifying the block toolbar across the basic text blocks, so they all share the same recognizable block toolbar, consisting of the Switcher, Alignments, and Inline controls (Bold, Italic, etc.). This would include at least the paragraph and heading blocks, and possibly more.
Mockups:
Original text:
Issue Overview
The component toolbar does not have any alignment tools for headings.
Steps to Reproduce (for bugs)
https://cl.ly/0m1B2v1f3A3i
https://cl.ly/0g3z2w1I162z
Chrome 62.0
Expected Behavior
Should be the same in both editors.
Current Behavior
Is not the same.
Possible Solution
Add the alignments tools.
The text was updated successfully, but these errors were encountered: