Change inline blocks workflow in Layout Builder to match mocks

How does this relate to #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder with all the changes in the last 2 months?

Going to work on a re-roll and CSS to match the mockup.

Here's the re-roll and button label change to match mockup. Just CSS and a back button left.

This patch adds a "Back" button from the block listing, and lots of styling to make this flow feel unique compared to other blocks. The styling and functionality is ready for review.

I think #17 needs UX review.

Agree with #17, although can’t think of a better name myself.

@samuel.mortenson thanks for picking this up, hopefully we can get this RTBC and committed in 8.7

@tedbow - I totally agree with you regarding the consistency of naming, my only concern is that users also associate custom blocks with being reusable and available anywhere on the site, the problem here is the blocks being added aren't reusable so that could also result in confusion for some users, for example "I added this custom block through Layout Builder, why is it not available anywhere else on the site, or even in any other Layout?".

I now have two competing thoughts in my head though:

The first is that in some ways it might almost be better for us to have that custom name for Custom Blocks since because they aren't reusable the end user (e.g. content editor, not a developer) doesn't need to know that technically they are just the same as any other block except they can't be reused.

My second thought is given that as soon as they click the "Add [whatever]" button it gives them a list of custom block types to choose from they might be confused as to what this list means, where it came from and how they can change it, especially if they have more than just Basic Block.

Unfortunately those two conflicting thoughts mean I'm not sure what the best way forward is, at the moment there doesn't seem to be a clear way forward that doesn't introduce at least some degree of possible confusion, but of course we need to do something so maybe there's a nice middle ground we can find somewhere.

Can we get a "before" screenshot so we can compare it to what's in the mockups?

Done.

I tested it, and it works.

The most recent patch doesn't apply anymore

1. +++ b/core/modules/layout_builder/css/layout-builder.css
   @@ -85,3 +85,33 @@
   +#drupal-off-canvas a.inline-block-create-button {
   ...
   +#drupal-off-canvas a.inline-block-create-button,
   ...
   +#drupal-off-canvas a.inline-block-create-button:hover,
   

   We should remove the element type from the selector. This should be only #drupal-off-canvas .inline-block-create-button.

2. +++ b/core/modules/layout_builder/css/layout-builder.css
   @@ -85,3 +85,33 @@
   +#drupal-off-canvas .inline-block-list a {
   ...
   +#drupal-off-canvas .inline-block-list a:hover {
   ...
   +#drupal-off-canvas .inline-block-list a {
   

   Could we add class for the links in the list? Something like .inline-block-list__item.

3. +++ b/core/modules/layout_builder/css/layout-builder.css
   @@ -85,3 +85,33 @@
   +  transition: background-color 0.5s;
   

   What is the reason for providing the transition? I tried to look at the Seven style guide but it doesn't mention anything about using transitions.

It turns out removing the anchor element from the create button's selector will make the css specificity too low, and it'll get overridden.
I decided to add a class to the container, and use that to combat this issue.
The other option, as @huzooka suggested, is to add a modifier class, and use that.

Kicking to review.

+++ b/core/modules/layout_builder/css/layout-builder.css
@@ -86,7 +86,7 @@
+#drupal-off-canvas .choose-block-container .inline-block-create-button {

@@ -95,15 +95,14 @@
+#drupal-off-canvas .choose-block-container .inline-block-create-button,
+#drupal-off-canvas .inline-block-list .inline-block-list__item {
...
+#drupal-off-canvas .choose-block-container .inline-block-create-button:hover,
+#drupal-off-canvas .inline-block-list .inline-block-list__item:hover {

@@ -111,7 +110,7 @@
+#drupal-off-canvas .inline-block-list .inline-block-list__item {

We should always use a single class as a selector. Off-canvas is a special case where we add the id selector behind the class selector to increase the weight.

Fixed!
My previous comment was a false alarm.
I accidentally used the patch from #2952390: Off-canvas styles override CKEditor's reset and theme, thanks @lauriii for pointing that out.

Thanks for making the changes @bendeguz.csirmaz! The front end parts of the patch look good for me now.

My first reactions upon @phenaproxima showing this to me is that:

1) Yay, that's a WAY better UX!
but
2) Yikes, we can't call that "Create new content" because we already say that somewhere else and mean something entirely different. (This was brought up above as well.)

Apparently the team already went through a bike-shedding exercise and ended up at "Create custom block" (since this is the existing entity label), which sounds much better to me. The only potential weirdness there is we call other things custom blocks that are re-usable, and this one is for the page we're on only. So we should probably open a follow-up to discuss how to make this clearer to people. But it doesn't need to block this patch, which is pretty awesome on its own.

Since this is just a label change, feel free to move back to RTBC once this is done.

Changed "Create new content" to "Create custom block" and adjusted the tests. Also attaching an "after" screenshot for committer happiness.

Found a typo that is fixable on commit:

+++ b/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php
@@ -428,4 +428,74 @@ public function testAccess() {
+    // Confirm with only 1 type the "Create custom block" link goes directly t
+    // block add form.

Should be "...goes directly to block add form."

Fixing the issue title.

Green is my favorite color. Returning to RTBC as per #38.

Awesome!!

Committed and pushed to 8.7.x and backported to 8.6.x. Thanks!