Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: Needs Design Feedback, [Feature] Write mode.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

I think we should get input from @WordPress/gutenberg-design for this one. I'm not opposed to it, but I'm also sold on the approach. With the click outside to exit and that you have to click the button from the inspector to access it (which means you'll know it's there), think it's OK. Also, since it appears at the top of the inspector for any selected block while in that state, it helps make it prominent.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: scruffian <scruffian@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: jeryj <jeryj@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +141 B (+0.01%)

Total Size: 2.47 MB

_{compressed-size-action}

Flaky tests detected in efb0509.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19173485317
📝 Reported issues:

• [Flaky Test] User Mention: should insert two subsequent mentions #48569 in /test/e2e/specs/editor/various/autocomplete-and-mentions.spec.js
• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js
• [Flaky Test] should select the wrapper div for a group #71211 in /test/e2e/specs/editor/various/block-hierarchy-navigation.spec.js

When you "focus" on a template part of a template or a synced pattern, the "document" tab becomes about the thing you just focused on. I wonder what it means here when we're focusing on just one block, does it mean the first tab should also be about that block that we're focusing on.

Thanks for the PR. Other behavioural aspects aside, there are a couple of details worth massaging:

• The button to exit is the same width as the document title interface
• Probably not feasible in a simple way, but mentioneing nevertheless: the rest of the top toolbar is "faded out", a la spotlight mode
• The button in the inspector is also intentionally removed from the mockup.

The third item I can see Jerry noting specifically, so in case there's a semantic reason for that to have to be there, we can keep it, but it does feel a bit duplicative for me.

I wonder what it means here when we're focusing on just one block, does it mean the first tab should also be about that block that we're focusing on.

I would say yes. It also means we could reuse the pattern that already exists for going 'back' to the parent rather than introducing something new. This one:

Except it would be more like:

It also means we could reuse the pattern that already exists for going 'back' to the parent rather than introducing something new.

I like using the document bar to show you where you're at instead of introducing a new button.

the rest of the top toolbar is "faded out", a la spotlight mode

I don't think we should fade out the header items. They are all still useful in the context of editing the focused design. I'd expect to still be able to access the list view and inserter, use undo/redo, change preview sizes, etc.

The button in the inspector is also intentionally removed from the mockup.

Sorry if my response was confusing. I like the "lock" button staying in the sidebar inspector because:

• You entered the mode from this spot. You should be able to exit from it as well. If I've walked into a new large office building from one door, I know I can exit from the place I came in. There may be other doors, but I want to have the waypoint instead of needing to exit from a new door.
• If we remove the button, where will should focus go? The canvas? The next item in the sidebar? If we leave the button, focus can remain on the button when it's activated.

My vote is to use the document bar to display the Back button and current pattern name, and also preserve the button in the sidebar for exiting.

It seems the general consensus is that this exploration went in the wrong direction. I'm inclined to agree! I'll close this and look into different changes to the document toolbar.

I would say yes. It also means we could reuse the pattern that already exists for going 'back' to the parent rather than introducing something new. This one:

I shared a slightly tweak of the document toolbar that taps into the back action in #73126 @jameskoster