Skip to content
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

Closed
jdelia opened this issue Dec 3, 2017 · 28 comments
Closed

Unify the block toolbar for all text blocks #3785

jdelia opened this issue Dec 3, 2017 · 28 comments
Labels
[Feature] Blocks Overall functionality of blocks [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@jdelia
Copy link

jdelia commented Dec 3, 2017

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)

  1. The classic visual editor has alignment tools for headings.
    https://cl.ly/0m1B2v1f3A3i
  2. The Gutenberg editor does not.
    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.

@Soean
Copy link
Member

Soean commented Dec 4, 2017

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.
heading_alignment

@afercia
Copy link
Contributor

afercia commented Dec 13, 2017

Feel free to argue why they should be added to the toolbar.

  • for consistency with the other toolbars
  • for consistency with the current experience in the classic editor
  • because we'd want to reduce the learning curve as much as possible
  • because the block advanced settings in the sidebar have discoverability issues, see User testing - Block settings hard to find #3340
  • 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

🙂

@youknowriad
Copy link
Contributor

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.

@jasmussen
Copy link
Contributor

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?

@afercia
Copy link
Contributor

afercia commented Dec 13, 2017

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.

@jasmussen
Copy link
Contributor

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.

@afercia
Copy link
Contributor

afercia commented Dec 13, 2017

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.

@pyronaur
Copy link
Contributor

pyronaur commented Dec 20, 2017

Feel free to argue why they should be added to the toolbar. @Soean

  1. 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.

  2. 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.

  3. I have never aligned a block-quote to the right in my life, yet the controls to align it to the right are there 😄

  4. 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?

@afercia
Copy link
Contributor

afercia commented Dec 21, 2017

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.

@jasmussen
Copy link
Contributor

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.

@karmatosed
Copy link
Member

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.

@mtias mtias added [Type] Task Issues or PRs that have been broken down into an individual action to take [Feature] Blocks Overall functionality of blocks labels Jan 25, 2018
@jeffpaul
Copy link
Member

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

@Axinet
Copy link

Axinet commented Feb 5, 2018

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!

@mtias mtias changed the title Unable to align or center headings Confusing how to align or center headings Mar 6, 2018
amdrew added a commit to amdrew/gutenberg that referenced this issue Mar 15, 2018
@amdrew
Copy link
Contributor

amdrew commented Mar 15, 2018

Count me in 👍

Perhaps this PR can be considered: #5635

screen shot 2018-03-16 at 12 35 24 am

It seems we should also remove the alignment controls from the block inspector? If so, I'll update the PR.

@karmatosed karmatosed changed the title Confusing how to align or center headings Unify the block toolbar for all text blocks Apr 18, 2018
@karmatosed
Copy link
Member

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.

@jasmussen
Copy link
Contributor

I took the liberty of updating the original ticket with the mockups from #5635 (comment).

@ZebulanStanphill
Copy link
Member

Related: #783 and #7227.

@talldan
Copy link
Contributor

talldan commented Jul 10, 2018

@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?

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Jul 10, 2018

@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.

@talldan
Copy link
Contributor

talldan commented Jul 11, 2018

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).

@ZebulanStanphill
Copy link
Member

Here is an updated mockup of what could be done with the Heading level switcher to make room for the text alignment controls.

gutenberg-heading-block-heading-level-switcher-mockup

@karmatosed
Copy link
Member

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.

@bph
Copy link
Contributor

bph commented Sep 3, 2018

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.

@jasmussen
Copy link
Contributor

Here's yet another updated mockup for the heading block, based on Zeb work in #3785 (comment):

after

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?

@GlennMartin1
Copy link

+1 to moving the Heading alignment buttons to the toolbar.

@mtias
Copy link
Member

mtias commented Apr 19, 2019

@jasmussen can you make an issue with that mockup and close this one? The above is more actionable.

@paaljoachim
Copy link
Contributor

paaljoachim commented Apr 20, 2019

This is what the current the paragraph block toolbar looks like. It should be added for all text blocks.
Screen Shot 2019-04-20 at 09 27 41

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:
Screen Shot 2019-04-20 at 09 36 51
@ellatrix

@jasmussen
Copy link
Contributor

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests