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

Replace default block appender in nested blocks with in-between inserter #6834

Closed
ZebulanStanphill opened this issue May 18, 2018 · 6 comments
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface Needs Design Feedback Needs general design feedback.

Comments

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented May 18, 2018

The problem with the default appender

Currently, Gutenberg uses the same block appender at the end of <InnerBlocks/> that it does at the end of the post. However, this introduces an issue in that it reduces the resemblance of the editor the front-end as the appender takes up extra space (the size of a single-line Paragraph). The problem gets worse the more you nest blocks, which is something that is bound to happen with things like the proposed Section block (see #4900) being used with the Columns block (or proposed Layout block as mocked up in a comment in #5351).

My proposed solution

In the context of nested blocks, the appender should be replaced with something that does not take up any extra space. I suggest that the in-between inserter be used here. The new design of the in-between inserter in #6818 in particular gave me the idea to make this issue, as it resembles the “+” buttons in the Divi Visual Builder, which take up no extra space, allowing the Visual Builder to look pretty much identical to the final page.

Speaking of the Visual Builder in Divi, I recommend checking out how it prevents toolbars and buttons from overlapping each other when things have no margins or padding to separate them. Doing something like that may help in situations where the nested blocks are as wide or tall as their parent, though the clever negative margin approach in #6773 will surely help as well (if not make the former unnecessary). Such margin/padding concerns with nested blocks are not directly related to my proposed change (as this would not affect the existing margins and/or padding separating blocks, and therefore no “+” icons would be unclickable due to overlap), but I thought I would point it out since in the long run it would be desirable to not have any (or have as little as possible) margins or padding that do not appear on the front-end, which will end up surfacing these kinds of issues.

Another benefit of using the in-between inserter as an appender in nested block contexts is that it may help get rid of the issue where you can insert a Paragraph block into any <InnerBlocks/> regardless of whether the Paragraph block is an allowed child or not. You would still have to disable the Enter functionality in those contexts, but that probably would not be too difficult. As it is right now, the block appender does not really work in the context of parent blocks limiting what kind of blocks can be inserted into them, as the appender immediately turns into a (provisional) Paragraph block when you click on it.

Related Issues and/or PRs

@karmatosed
Copy link
Member

@SuperGeniusZeb thanks for the in-depth suggestions. I wonder if the recent changes to the sibling inserter change your perspective on this at all?

@chrisvanpatten
Copy link
Contributor

chrisvanpatten commented Jun 25, 2018

I'd go a step further and say the in-between inserter should always be available after the last block in any context (nested or the full content), regardless of whether the default block appender is visible. I understand that's not a quick thing to change due to some of the way the in-between inserter is built, but it feels like a change with lots of upside (consistency, namely) and little downside.

@ZebulanStanphill
Copy link
Member Author

@karmatosed Recent changes to the sibling inserter have actually made it end up looking even more like the Divi Visual Builder, which is certainly not a bad thing, in my opinion. Actually, I think at this point the sibling inserter in Gutenberg may look better than the one in Divi.

Somewhat related: Recent changes to the hover outlines have helped with the editor-should-look-like-front-end issue a lot without sacrificing the ability to select the parent block, though there are still a few cases where selecting the parent block is difficult. See this comment on #6459.

However, the issue of the placeholders (which add quite a bit of space that does not exist in the front-end) still exists and should still be addressed.

Notably, placeholders currently do not appear after Paragraph blocks, which I think is rather confusing. Since the sibling inserter is not shown after these Paragraph blocks like I am suggesting, there are only 2 ways to insert a block after a Paragraph block at the end of a context: the Add block button in the top bar of the editor and the Enter key.

I would prefer if the block placeholder was never automatically added in nested contexts and the sibling inserter was always shown at the end of a context, as @chrisvanpatten suggests. Actually, I think perhaps the placeholder should never be automatically be added in any context.

In this comment by @chrisvanpatten, he suggests an alternative solution to the related issue of placeholders not respecting the list of allowed children blocks since they are themselves Paragraph blocks. I think his idea could work better than my suggestion of not having placeholders at all for nested contexts that disallow Paragraph blocks and having the sibling inserter open the block library directly. Whatever the case, however, I think placeholders should not be added automatically in nested contexts, and probably should not be added in any context.

@karmatosed
Copy link
Member

Let's focus on the approach we have right now for this and consider iterations in the future. We are on a good track with the sibling inserter right now and a lot of iterations have happened. Noting we can always reopen issues so closing just to note direction.

@ZebulanStanphill
Copy link
Member Author

@karmatosed Just to be clear, the current direction is simply making the sibling inserter unavailable and not automatically adding placeholder blocks in situations where the default block (Paragraph) is not allowed to be inserted?

You will want to close #7950 as well if you are closing this issue.

@chrisvanpatten
Copy link
Contributor

I got a report from a client about this today. Was very confused on how to add new blocks to a column area.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

No branches or pull requests

5 participants