-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Always show the block appender when its parent is selected #36656
Conversation
Size Change: -244 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
Just for consistency, I agree: either we always show, or we never show. But I'd like very much for this one to be paired with 36605 so we don't have plusses everywhere. Thanks Riad! |
I agree that this one doesn't work well without #36605 |
4e30d97
to
a3eb290
Compare
Glad this is finally being addressed. I tried doing something similar in #28529 but ran into some end-to-end test failures. I think this PR will finally resolve #5055. I'm noticing some odd behavior when clicking on the bottom of the editor canvas. To see what I mean, go into a mostly empty post, add a Paragraph, add an Image (just leave it as a placeholder), then click below the Image. The cursor jumps to the Paragraph for some reason. This is not how it behaves in |
@ZebulanStanphill That's probably a bug that's already in trunk but hidden. In trunk, there's an appender that is always visible after the last image block while in this PR, there's nothing, so the click is forwarded to the first block maybe? What would be your expectation here? |
@youknowriad I would expect the last block to be selected. The current behavior in |
Definitely. However I'm starting to think of that as a mostly failed experiment mostly resulting in empty trailing paragraphs, and difficulty in deselecting blocks that's increasing a bit with the site editor. I'm tempted to think it's worth revisiting/reverting that code, essentialy addressing #5803. |
@jasmussen I agree. Now that the root appender only shows when no blocks are selected, I found it confusing that clicking the empty bottom of the canvas didn't take my selection off the blocks, yet clicking the empty left/right regions did. |
a3eb290
to
8f90864
Compare
@ZebulanStanphill @jasmussen this makes sense, I tried it in the last commit and it feels good for me. WDYT |
The fact that I can deselect without creating an empty paragraph feels right. It also works well for groups: There's one single place in the entire codebase where I feel like the old behavior was better, and that's the navigation block for creating submenus. The details are in this PR which sort of restores the behavior, though that would break with this PR. I don't mean that to be a blocker: I think there are other paths we can take. But I do wonder: should there be some way the block itself could opt in to the "show appender even when a child is selected" behavior? It would make sense for submenus. |
It should already possible to do this somehow with the |
Sounds good! |
04ff359
to
7e19676
Compare
Works perfect 👌 |
1e8c5a6
to
e5f4041
Compare
Can I get a ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works well for me, and is an important followup to recent abs-position improvements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good riddance. :) It's nice to be consistent and remove the canvas click redirect.
I'm hesitant about the "backport" label here. What do you think? |
I guess this change is mostly invisible on top of the already merged fixed appender change. In that light, whether it lands or not is less important? |
closes #5055
closes #5803
Builds on top of #36605
This PR simplifies the behavior the default block appender:
This basically removes the special case we had in place about the last paragraph in a block list being a paragraph.
Let me know what you think @jasmussen