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:_
The component toolbar does not have any alignment tools for headings.
Chrome 62.0
Should be the same in both editors.
Is not the same.
Add the alignments tools.
Hey @jdelia,
thanks for your ticket. The alignment tools were added in #1383 to the inspector.
Feel free to argue why they should be added to the toolbar.
Feel free to argue why they should be added to the toolbar.
π
quoting @jasmussen : because design principles state that you should never put anything into the sidebar that is necessary for the basic operation of your block
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.
quoting @jasmussen : because design principles state that you should never put anything into the sidebar that is necessary for the basic operation of your block
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?
So SALTY
π
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.
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.
Feel free to argue why they should be added to the toolbar. @Soean
I searched GitHub issues to find out whether an issue about this has already been created - because I couldn't find how to align text to center.
I think that the sidebar "Blocks" area should be reserved for "additional" options (funky headlines, custom sizes, letter spacing, any other crazy stuff). Because headlines are text blocks, just like paragraphs and quotes - they should have the same controls.
I have never aligned a block-quote to the right in my life, yet the controls to align it to the right are there π
95% of headlines are bold, yet there is a bold button for headlines
4.1. On top of (4) - could the bold button give the user an expectation that they can turn a bold headline into regular font weight?
I have never aligned a block-quote to the right in my life, yet the controls to align it to the right are there π
π¬
95% of headlines are bold, yet there is a bold button for headlines
π¬ Good points, both. For example, headings in Twenty Seventeen use font-weight: 300;
but in Gutenberg they are displayed bold. So, the "Bold" button seems useless but actually makes the heading weight in the frontend change from 300 to 700.
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: https://github.com/WordPress/gutenberg/pull/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 https://github.com/WordPress/gutenberg/pull/5635#issuecomment-378563300.
Related: #783 and #7227.
@mtias You mentioned this issue yesterday as a good one for me to take a look at. Is the plan to use Block Styles as introduced in this #7362 for the heading levels?
@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:
styles: [
{ name: 'default', label: __( 'h1' ), mergeAttributes: { level: 1 } }
],
mergeAttributes
are attributes that can be overwritten by the style (shallow merge). This would still let a theme break a block, but we could introduce a second rule that only attributes with a whitelisted set of values can be overwritten. An attribute could look like this:
level: {
type: 'number',
default: 2,
validValues: [1, 2, 3, 4, 5, 6],
}
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).
Here is an updated mockup of what could be done with the Heading level switcher to make room for the text alignment controls.
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 https://github.com/WordPress/gutenberg/issues/3785#issuecomment-405449955:
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 https://github.com/WordPress/gutenberg/issues/3785#issuecomment-418162066 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/
Btw it would be helpful to see the shortcut for each option that are in the drop down. Similar to this example from Photoshop:
@ellatrix
@jasmussen can you make an issue with that mockup and close this one? The above is more actionable.
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
Most helpful comment
π