Gutenberg: Toolbar Behaves Differently When Fixed vs. Floating Contextually For Paragraph Block Only

[0aveRyan]

Describe the bug
In the default contextual floating mode, the formatting toolbar only appears if characters exist within a Paragraph Block _(i.e. a user must create and then format)_.

However, when the Toolbar is set to Fixed mode, formatting controls are always available to users, allowing them to align, bold, etc prior to writing any text _(i.e. a user can create and then format, or format and then create)_. This latter flow mirrors the current Classic Editor, always making these controls available to users and more closely mirrors industry-standard pattern for Word Processors / Page Layout tools.

Notably, all other blocks including other text-based blocks like Heading, Subheading and List surface the formatting toolbar 100% of them time so no order of operations is enforced on a user.

I attempted to search issues to see if this was a design decision, but couldn't find a ticket. If this was a deliberate decision, I'd advocate it be revisited for a less restrictive solution that kept the Toolbar behavior unified regardless of where it's positioned.

To Reproduce

1. Open latest, unmodified version of Gutenberg (without Fix Toolbar to Top enabled).
2. Try to access formatting controls in initial Paragraph Block or any Paragraph Block in the document (when P Block is active, move your mouse/keyboard cursor around -- nothing happens)
3. Toolbar will not appear until characters are present in the Paragraph Block.
4. Open Main Menu and enable Fix Toolbar to Top.
5. Empty Paragraph Blocks can now be pre-formatted.

Expected behavior
Considering every other Block has the formatting toolbar available even when empty, I expect the Paragraph Block's Toolbar to behave the same.

Screenshots

Additional context

• Gutenberg 3.5.0

[0aveRyan]

Persists in 3.6.2

[youknowriad]

The toolbar is also available directly in RichText components if the toolbar is not fixed at the top. The difference is that we hide all toolbars from the "empty paragraph block" because this block also serves as an entry point to switch to other blocks:

• using the quick inserter (the buttons on the right of the block)
• or the / command

If we should the toolbar and the quick inserter at the same time in paragraph blocks, it will create a heavy UI.

[0aveRyan]

The toolbar is also available directly in RichText components if the toolbar is not fixed at the top

@youknowriad could you provide an example? I've searched the UI, markup and keycodes and don't see a way to trigger the toolbar?

I appreciate why this behavior is unique to the Paragraph block and the desire to avoid a "heavy UI," but this adds a different but equal kind of heaviness and weight to the UI/UX by creating disparate behaviors depending on Toolbar position, creates a distinctly unique behavior for the most common block, makes documentation/instructions challenging, etc.

It's a departure from current always-available controls in Classic Editor and obstructs a common workflow of applying formatting before typing. I don't think it's enough to simply offer a user recourse to format later or select formatting, delete content and recreate.

Some ideas:

• Longer-than-standard hover delay on toolbar appearing (stay out-of-the-way, but appear when user hasn't typed)
• Block Menu toggle (for P-block only)/Keyboard toggle to show/hide toolbar.
• Present button trigger or condensed version of Block Toolbar in the Sidebar

[youknowriad]

@youknowriad could you provide an example? I've searched the UI, markup and keycodes and don't see a way to trigger the toolbar?

On paragraphs blocks you can't trigger it unless you type something

It's a departure from current always-available controls in Classic Editor and obstructs a common workflow of applying formatting before typing. I don't think it's enough to simply offer a user recourse to format later or select formatting, delete content and recreate.

Being a departure from the classic editor doesn't mean it's wrong. With Gutenberg it's expected that existing users have to change some habits and learn a new way of doing things. A better comparison is whether it's easier to create Rich pages/posts with Gutenberg compared to the classic editor for people not familiar with any of those.

That said, I'm not a designer, I'm just trying to explain the reasoning here. I'm adding the Design Feedback back to see if the decision is made or we can tweak this more.

[0aveRyan]

@youknowriad I appreciate you taking the time to explain and also agree departure from Classic isn't inherently bad/that some habits will require updating.

I'm not advocating entirely reversing this behavior -- I think hiding the toolbar still results in net-positive -- but I'd love to have _some way_ to trigger the toolbar without content in a Paragraph. Without it, it feels like we're rescinding control from a user. _(Another small confusion point that results -- keyboard shortcuts for Bold/Italtics show gray formatting boundary, but without displaying Toolbar there's no visual cue what formatting action is being taken)_

Worth highlighting this ingrained habit has many origins:

• Microsoft Word, Google Docs and other RTF applications have historically enabled a visual-based workflow for format-then-create by having always-available formatting toolbars.
• Medium and Canva also let creators apply formatting to text prior to writing, with contextual toolbars appearing/disappearing.
• Writers used to dip quill into ink prior to parchment.
• Artists dip brushes on a palette prior to painting on canvas.

[earnjam]

Doesn't solve it entirely, but I do think the keyboard shortcuts for bold/italics should always trigger the formatting toolbar to appear on a paragraph block.

At that point you are likely intending to using it as a paragraph block and it's not just the entry point to another block. And since you've already applied some formatting, it would be helpful to know what formatting has been applied before typing.

It seems to work intermittently right now. If you _click_ onto an empty paragraph block, then it will trigger the toolbar to show when typing cmd+b or cmd+i. However, if you navigate to an empty paragraph block _via keyboard_, then it won't show the toolbar with a cmd+b or cmd+i, and only displays once you type some content.

[0aveRyan]

the keyboard shortcuts for bold/italics should always trigger the formatting toolbar to appear on a paragraph block.

@earnjam I think this would definitely help, and resolve my point about not knowing the formatting action. If the only change is adding this, I worry its still not highly evident to a user, nor does it allow a user to start from a selection of formatting options... but it would at least offer one way to trigger the toolbar.

I think the nuance is, even if keyboard shortcut is the trigger to make the Toolbar visible, the toolbar would need to persist so that I could do the following with an empty paragraph
1) keyboard shortcut to bold
2) unbold via toolbar button
3) then italics via the toolbar button.

[jasmussen]

This issue is likely to be fixed when #10385 is addressed, so removing design feedback label.

[aduth]

This issue is likely to be fixed when #10385 is addressed, so removing design feedback label.

I couldn't decipher much a difference between #10385 as describing the issue, or at least it's not clear to me what the actionable task is.

https://github.com/WordPress/gutenberg/issues/9063#issuecomment-415738842 provides some context on describing this interaction as an indeterminate state of adding a block.

Thus, the options for action items as I see it are:

• Apply this behavior consistently, including to hide the paragraph controls from the toolbar in Fixed Toolbar mode when empty.
  
  
  
  • Needs additional consideration for (a) displaying the toolbar on formats applied and (b) if/how to delete the empty block (#10385)
  
  
• Stop making this distinction and just show the toolbar.
  
  
  
  • Optionally in combination of removal of the "Quick Insert", for which I had thought there might have been some prior discussion on whether it's in-fact a valuable UI. Needs design feedback.