Try: Make appender fixed position. #36037
Conversation
|
Size Change: -514 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
|
With the appender appearing on the border of the container, it feels like it's intended to insert next to the container, rather than into it like it actually does. I think that the appender should instead be attached to the last child block of the container. That would work a whole lot better in the wrapping buttons scenario, for example. Perhaps also shift the button down (for vertical flow) or to the right (for horizontal flow) to avoid overlapping the content of the block it appears after. |
|
I don't necessarily disagree, but a key part of avoiding a layout shift is the need to remove the item from the DOM. That can either be done by positioning it entirely via JS, or use position absolute which then limits our options for positioning relative to anything other than the container. I could put it in the bottom right corner, but it remains tricky:
|
|
Let's try the sitting on top of the line. It might not work, but we have been postponing improvements here for so long it's degrading the experience with all the layout shifts. |
|
I think the design currently used by this PR is very confusing. It looks like it inserts a sibling of the selected block (compare with the current sibling inserters that appear on hover), but it actually inserts a child. I think it would be clearer to just add a toolbar button for inserting into the current block:
A nice benefit of this design is that it's more obvious which block you're inserting into, since the insert button is clearly associated with the current block. Additionally, the button is also always visible, whereas currently you tend to have to scroll down to find the appender. I assume it would also be a lot less complicated to handle, CSS-wise. With some block-specific icon tweaks, we could also make it more obvious when this button would insert a specific block (e.g. a Button into a Buttons) versus opening the library (e.g. inserting stuff into a Group). Fixed position appenders like the ones in this PR could be repurposed for inserting siblings, which would fit their design a lot better, in my opinion. |
ZebulanStanphill
added
the
[Feature] Inserter
jasmussen
force-pushed
the
try/fixed-position-appender
branch
from
eaacedf
to
c73024b
Compare
jasmussen
force-pushed
the
try/fixed-position-appender
branch
from
c73024b
to
8bb18e0
Compare
|
Alright, I've taken a stab at refactoring this one to hopefully bring it to a state where it might land. I agree with the feedback that this needs better solutions, for example replacing it entirely in favor of the sibling inserter or possibly the block toolbar solution. And so I don't consider this PR to be the end-all solution, but rather a step on the way. The problem is the layout shifts it's causing in the site editor are so disruptive that it's reducing the entire experience. Here's where I've landed:
Take-aways:
It really comes into its own in the site editor, however in doing so it surfaces a different issue: The current behavior is for the in-canvas appender to show up both when the parent is selected, and when a child is selected. That's why in the GIF above you can sometimes see the plus seemingly "hanging there". One quick fix I can make here is to show the plus only when the actual container is selected, not when a child is selected. Let me know what you think. Just for regression testing, here's some test content you can use: but I do recommend testing primarily in the site editor. |
|
@jameskoster I'd love your thoughts on this one. |
💯
I think this may be worth trying. The "hanging" inserters can really be quite awkward.
I think it works ok on row orientations, but on columnar layouts it feels a bit misleading. Consider this example:
My expectation here is that a block added via this inserter would appear adjacent to the selected group, which isn't the case – it appears beneath it. I'm not sure how big of a deal this really is in practical terms, but I wanted to note it regardless. Perhaps we can adjust the position based on whether the block is a row or not? One other issue I spotted: on blocks that span the full width of the canvas, the inserter is now only accessible via horizontal scroll: scrol.mp4I appreciate this is an unpopular opinion, but I would be in favor of removing this inserter altogether, perhaps only in the Site Editor to begin with, but probably in the post editor too :) There are many ways to insert blocks, and I'm just not seeing the value of this one based on the annoying layout shifts, and difficulties in circumventing that. The sibling inserter allows you to inject blocks between others. The primary inserter in the top bar will insert the block in to the selected container. What purpose does the appender provide that is not covered by those other two inserters? |
|
Great thoughts, thank you for looking.
There's really no way for me to tell using just CSS, so that's not really something I can do as a small interim iteration. And perhaps that's worth reiterating: this PR is an experiment to see if we can ship 5.9 without layout shifts on select. I would hope we have something better for 6.0. That's also a good way to frame the feedback: what fixes can we make to land this for 5.9?
Oh I am too! And I do think the sibling inserter, especially if we address #35536, can replace this one and be a good experience.
The sibling inserter lets us do this:
But it doesn't allow us to do either of these; insert after the last block in a container:
Insert before the first block in a container:
Notably for the "Buttons" use case, it really seems like there needs to at least be an "insert after the last block in a container" behavior in place [horizontally], no? Depending on additional feedback, the todo-items (note to self):
|
What if the sibling inserter was updated to also appear before the first block in a container, and after the last block? 🤔 |
|
Yep, I'm saying I think that would work. I just also assume that's non trivial to do. |
priethor
added
the
[Priority] High
|
Alright, for folks subscribed to this one, here's a small status update. The problem to solve remains to avoid the layout shifts that happen when you select a nesting container and the "Plus" button appears. It's important to keep this in mind, because the experience that's shipping is definitely compromised by those shifts, especially in the site editor, and it's the primary reason why we should consider an interim solution to the problem, and then come back with a better long term solution to replace it. I have three different PRs that aim to solve this: 1. What you see in this branch (36037). It affixes the plus to the top right of the container, makes it small and blue.
2. #36602. This one entirely hides the plus, but only in the site editor.
3. #36605. Based on 36037, but doesn't visually change the plus, and places it in the bottom right corner of the container.
Of the three, I personally prefer 2 or 3 as they feel like smaller changes. Let me know your thoughts. |
|
Nice! For 3 did you try making the appender only appear for the closest container? I noticed that when you select the buttons block, the appender for the containing column still popped up in addition to the one for the buttons block. I'm also wondering how the [+] interacts with right-justified content, the overlap seems like it could be a little awkward? Overall I like 2 and 3 the most as well, with a slight preference for 2 as I feel we've over-indexed on inserters and the appender seems to be the least useful on balance. |
|
I tried that just now, and it's easy enough to get to work for the inner containers: However it appears there's an issue attached to that which relates to this same component being used for an empty group block which shows the white plus. I'll see if I can get it working there as well. |
|
@jameskoster okay I have a fix working that I can push to #36605 if we like it. It works like the GIF I just shared, but it does come with this downside: That is, you now have to select the exact container in order to get the inserter to appear. In the case of the buttons block, that means the inserter disappears when you select a button (singular). We could consider that a boon, but wanted to just sanity check before I push it. What do you think? |
|
I'm inclined to say that's probably ok. Once again it feels like the lesser of two evils. But ultimately I feel this just adds more weight to the idea of getting rid of it altogether. There are just so many quirks and compromises around this thing 😅 |
|
Thanks, I pushed the fix.
Actually I think the fact that we are seriously looking at these temporary fixes acknowledges how bad the situation is, and that it needs a developer. That isn't me advocating for one solution over the other (though 3 is growing on me), just that I have full confidence this will finally get the attention it needs. |
|
Closing in favor of #36605. |
Description
This PR is a followup to #31886, to see if it would be possible in using only CSS to take the in-canvas appender out of the flow. The key problem to solve is to prevent the current layout shift that happens when you select a block:
This happens because the appender shows up in the DOM and is therefore treated as if it were another block. In the case of flexed containers that space-between, that means there's another item to make room for. This PR makes that a fair bit less jarring by positioning the buttons on the focus border:
That's also a bit of the challenge at the moment, as the border is present only on focus, which means as soon as focus moves inside the inserter, the button sits there, disconnected:
It feels like this should be solvalbe, whether through more liberal use of the
is-highlighted.An additional challenge is the abs-positioned nature of it. It looks good in the use cases shown above, but when things start to wrap on multiple lines, it's a bit less optimal:
I feel like all of this is solvable with design, but curious of your thoughts.
Checklist:
*.native.jsfiles for terms that need renaming or removal).