Block List: Always show trailing inserter

[aduth]

Partially addresses: #10519 closes #11329

This pull request seeks to update the block list to always display a trailing inserter menu.

Status: In its current form, it is very much a stub branch to prompt discussion around the interactions. Notably:

• If the dashed border of the trailing inserter is undesirable, would its removal be detrimental to its purpose having been introduced in Add an alternative block appender when the container doesn't support the default block #10136 ? How do we ensure consistency here to avoid having two appearances for what is essentially the same interaction?
• What should be initially shown to the user when they start drafting a New Post. If the purpose of In-Page Inserter Revisions #10519 is consistency in the behaviors surrounding the appending of a new block, should that also mean it's the only option available for a new post?
• Should the clickable area below the block list remain? Its purpose was to mimic the feeling of any other text editable region (word processors, textareas like the one in which you're soon to comment), but it may feel out of place with the more block-oriented nature of the always-visible trailing inserter.

[ZebulanStanphill]

Yeah, this is pretty bad for nested contexts, if you're trying to make the editor look like the front-end. Why can't the sibling inserter be shown after the last block instead? Thanks to #11018, it now opens the inserter menu directly, so it would work in all nested contexts, regardless of whether they allow a Paragraph block or not. In fact, the first version of #11018 made that change and it worked great, but due to technical issues it had to be reverted.

Personally, I think this default inserter should only appear when there are no blocks in the context and the Paragraph block is not supported, e.g. an empty custom post type that doesn't allow text-related blocks or an empty block with nesting that doesn't support the Paragraph block as a child.

[ZebulanStanphill]

Another idea I just had: only show the appenders when you have selected the context they appear in, e.g. an appender would only appear in a Column block if you had selected the Column block or one of the blocks inside the Column. (Empty Column blocks would be an exception where the appender is always shown.) The appender at the bottom of the post could always be shown, but I would prefer if it was only shown when a block at the root level of the post was selected.

I prefer the sibling inserter idea I talked about in my previous comment, since it doesn't cause changes in height to constantly happen, but this idea might work as well. Actually, both could be implemented, since they don't technically conflict with each other.

[paaljoachim]

I am just throwing this in here....
What about clickable hot spots? As in click the area below the last block and have the inserter show up.

[afercia]

Should the clickable area below the block list remain?

I'd be in favor of removing it for a few reasons:

• it's inconsistent: it's there only after non-paragraph blocks and it's very unlikely users understand the sophisticated reasoning behind that. I guess users just wonder why clicking on the area after the last block sometimes works sometimes doesn't
• it's basically a hack: it's a readonly textarea with a role="button", the rendered markup is: <textarea role="button" aria-label="Add block" readonly .... See The blocks "appender" misses a label #4829 / Accessibility: Fix Block Appender Accessibility #5742 for the reasons behind this implementation. It would be nice to get rid of such an hack
• the trailing inserter with a bigger clickable area proposed here basically acts like the current clickable area, with the advantage that it's a visible user interface control and thus benefits all users

[gziolo]

closes #11329

@youknowriad you updated the description in a way it references PR :)

@aduth what's the status of this one? Who should leave their feedback? @jasmussen @kjellr and @mapk (it would be nice to have a group ping for designers involved in the project willing to participate in such discussions)? Anyone else?

[aduth]

Admittedly my opening of the pull request was in large part to highlight issues we have with inconsistency in how we treat inserters. To that end, I'd certainly invite feedback from designers, but I don't think this pull request provides much value in its current form as far as something which would be merged. It probably makes more sense for discussion to continue in the original issue #10519, with this serving as some prior art for the issues associated with naively displaying the trailing inserter interface everywhere.