Improve writing flow for lists by capturing list item toolbars #53306
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
richtabor
added
[Type] Enhancement
|
Size Change: +15 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 1775c7e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5752797551
|
42 tasks
There was a problem hiding this comment.
The intent behavior seems to change in the "After" screencast.
The "Before" behavior is consistent with Google Docs and Microsoft Word Online:
Google Docs
google-docs-lists.mp4
Microsoft Word Online
CleanShot.2023-08-03.at.14.09.41.mp4
Is this an intentional change?
|
Tested this out and noticed the flashing of the toolbar is a bit odd when selecting different items in the list. At a certain depth, the toolbar also jumps to the bottom seemingly at random: toolbar.movOtherwise, I really enjoyed not having the toolbar blocking other list items. That's a pain point right now! |
|
Excellent PR, I think this is an improvement. I could see this potentially benefitting many other nested blocks, but List is an obvious one. Anne captures well one of the challenges we have with this, but I wonder if that's an issue to fix separately? And if yes, is this a step forward in the mean time? (I'm leaning yes, but opening here for conversation.) |
|
This definitely improves the selection experience and feels like a good change overall.
I had the same thought. There is a trade-off though – the increased distance between the block and its tools can make performing some actions more tedious than before. It almost starts to verge into 'top toolbar' territory: distance.mp4 |
I'm not following. This is changing the toolbar inheritance, not the actual indent/outdent functionality. |
Makes sense. The indent/outdent behavior appears to be different between the "Before" and "After" videos. I wasn't aware that Gutenberg already differed from other editors. Feel free to ignore me 😊 |
Agreed! Details and submenu blocks do already.
Yea, I found this to be the case in trunk as well. I need to replicate it better and write up an issue.
Yes, this is the biggest trade-off. I think it's worth the trade though. |
|
I wonder if it's worth boosting confidence by exploring where else this pattern might be applied before committing? It could be used for:
It seems to make sense in all of those scenarios. What do you think? |
|
Paragraphs in quotes sounds like a good next one to do, and start mostly with the text ones. Groups are a more open question since they can grow so tall. Row and stack could also be candidates, but definitely gets fuzzier there. |
|
I don't have a strong opinion here. |
I think groups, and their variations, would probably be better suited as-is. But some of the other ideas I'm down to explore and see — lots of potential. |
This was referenced Aug 15, 2023
|
Alrighty, I made PRs for navigation #53697, quote #53699 and gallery #53700 blocks. I don't think capturing quite works for columns/groups/media & text blocks, as those have much less predictable dimensions (and one caveat to using capture is that the toolbar is at the top or bottom of the parent block). I still think capturing on list is a nice improvement as well. Would appreciate a review on this and the related PRs. 🙇 |
|
I think it works great for quote and navigation, approved those 👍 👍 |
jasmussen
approved these changes
Aug 16, 2023
There was a problem hiding this comment.
I'm happy to try this because the consistent position of the toolbar for moving, and the fact that in fewer cases it overlaps preceding text, that benefit outweighs the challenges the captured toolbar otherwise has, notably that it can, with no animation or other indication, suddenly jump to the bottom like Anne mentions:
So I still think we need to improve that separately, but I can also see this improvement in the meantime.
|
I think this could aggravate #46040, making it look like you execute block actions on the whole block rather than a single list item? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Improve writing flow of list items by capturing the toolbar for each list item in the parent list block.
Why?
As-is, adding a new item blocks the previous one. It's also difficult to select other items in the list without first selecting the parent list block (have to click in the small space between the current list item and its toolbar.
Testing Instructions
Screenshots or screencast
Before:
CleanShot.2023-08-03.at.11.32.21.mp4
After:
CleanShot.2023-08-03.at.11.30.28.mp4