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

Layout: Expand editor canvas as flex region #5424

Merged
merged 2 commits into from
Mar 8, 2018
Merged

Conversation

aduth
Copy link
Member

@aduth aduth commented Mar 6, 2018

Closes #2322

This pull request seeks to use flex styling to ensure the visual editor canvas occupies the full height of the screen, thereby enabling users to clear the selected block by clicking below the editor on a new post.

One noticeable difference in this implementation is that, when meta boxes are present, they will be pushed to the bottom of the viewport rather than appearing immediately below the post content.

Before After
Before After

Testing instructions:

Verify that with and without meta boxes, and with and without long content, that...

  • Meta boxes appear at the bottom of the screen / post
  • If there is any space below the post content (e.g. new post, it can be used to deselect the currently selected block)

@aduth aduth added the General Interface Parts of the UI which don't fall neatly under other labels. label Mar 6, 2018
@youknowriad
Copy link
Contributor

Just a small note about the meta boxes. We had a strong pushback against this. People expect the meta boxes to show like content in may cases.

@jasmussen
Copy link
Contributor

This seems to vastly enhance the Gutenberg editing experience.

Here's the canvas change in GIF form:

flexcanvas

As is shown here, the issue with the metaboxes being at the bottom is primarily an issue for the "empty page". This tradeoff seems definitely worth making, because the ability to deselect early blocks by just clicking below the block in the large visible space, is such an improvement to the past behavior. It almost feels like the gloves coming off.

However Riad touches on a good point, we did receive pushback back when metaboxes were in what looked like a detached panel. So just for due diligence, I'm CC'ing the leads to make a call: @karmatosed @mtias.

Personally, I would give the go-ahead on this one for one simple reason: the disconnect between metaboxes at the bottom and an empty canvas above happens only when those metaboxes are collapsed:

screen shot 2018-03-06 at 10 13 31

Since metaboxes maintain their state of being opened across sessions, on balance this seems like it should not be a blocker for enhancing the deselectability of blocks.

👍👍 from me, but good to get a call from the leads.

@aduth
Copy link
Member Author

aduth commented Mar 7, 2018

Personally, I would give the go-ahead on this one for one simple reason: the disconnect between metaboxes at the bottom and an empty canvas above happens only when those metaboxes are collapsed:

Yes, my original example was maybe not the best to show a single collapsed meta box, which would appear at the bottom of the screen.

But the natural behavior here is that meta boxes will expand upward if there is space, and share the available canvas with content, with a preference toward content pushing meta panel downward once enough exists (as it does in master).

@aduth aduth force-pushed the update/space-below-editor branch from 2951e7f to 9b521ce Compare March 7, 2018 16:20
Clicking visual editor is not very reliable because clearing is dependant upon where click occurs. Escape is most reliable for intent of clearing the focused selected block.
@aduth aduth force-pushed the update/space-below-editor branch from 9b521ce to 027149b Compare March 7, 2018 16:41
@mtias
Copy link
Member

mtias commented Mar 7, 2018

Let's get this in, it seems like a good balance of usability and design.

@aduth aduth merged commit d8bc60d into master Mar 8, 2018
@aduth aduth deleted the update/space-below-editor branch March 8, 2018 00:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants