Sticky Position: Make help text aware of whether or not there is a parent block #47230
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
andrewserong
added
[Type] Enhancement
This was referenced Jan 18, 2023
|
Size Change: +170 B (0%) Total Size: 1.33 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 2bb0a44. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3945842727
|
|
Do we still need to mention scrolling in the description? |
jameskoster
added
the
Needs Copy Review
|
Hello! Thanks for the copy review ping. @jameskoster said:
Not necessarily. You could say:
|
|
I wonder if we do need "when scrolling" on the end of both, because there might be an expectation that it sticks immediately on selection? |
Oh, that's a great point actually, it'd help to make the behaviour of sticky explicit, especially for if and when we eventually add |
|
Okay, I've updated it to the following:
Here's how it looks, I think this is probably my favourite wording so far, personally:
|
|
For visibility, just pinging another couple of folks for input on the idea in this PR (@mtias and @tellthemachines). To recap: the idea in this PR is to try to improve the UX when the sticky position is available and the block is set at a non-root position. This PR currently aims to clarify which block the current block will stick to when scrolling. Another potential idea could be to hide the position controls if the block is in a non-root position and doesn't have a position set — we could use similar logic to this PR but instead of switching the help text, we'd hide the position controls altogether. Happy to give that a try if folks think that's a better first step! |
|
I like the idea of focusing on the root level only because it reduces the complexity and unanswered UI questions (for example, how we show these on the list view). The one thing it raises is the need to express a layout property of the root element (global styles > layout) so that there is no need to have a group wrapper at the top level to achieve flex stack effects. |
This was referenced Jan 22, 2023
Thanks for confirming. I have opened up a follow-up PR to hide the controls if the block is non-root: #47334. Thanks for all the feedback, everyone! I'll close out this PR now in favour of #47334, but happy to revisit this if and when we start looking at support for non-root level blocks.
That's a cool idea, it'd be good to explore irrespective of what we do with sticky positioning. |
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?
Part of #47043
Make help text for Sticky Position controls aware of whether or not there is a parent block, and conditionally change the help text to refer to sticking to the top of the window, or the top of the parent block (including that block's name).
The proposed text so far:
'Sticks to the top of the parent %s block.''Sticks to the top of the window instead of scrolling.'Happy to change this text to whatever works the best here.
Kudos @richtabor for the idea!
Why?
This PR is an alternative to #47207, but has a similar objective of trying to improve the UX surrounding Sticky Position support by making it clearer to the user where and how the sticky position will be applied. This PR is a fairly subtle change, but makes the help text more explicit based on the context of where the block is located.
How?
In the
PositionEditcomponent, check to see whether or not there is a block parent. If so, use its display title in the help text message for the sticky option. If not, default to the help text indicating the block will stick to the top of the window.Testing Instructions
Screenshots or screencast