ToggleGroupControl: add new opt-in prop #47269
Merged
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
|
Size Change: -2 B (0%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in be948e2. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4049480293
|
49 tasks
mirka
approved these changes
Jan 26, 2023
| @@ -598,6 +598,7 @@ function Navigation( { | |||
| ) } | |||
| <h3>{ __( 'Overlay Menu' ) }</h3> | |||
There was a problem hiding this comment.
I wonder what this h3 with the wonky margin is doing here 😭
There was a problem hiding this comment.
😬 Maybe not in this PR since it cascades into more than just a line change, but would it make sense to remove the prop hideLabelFromVision from the ToggleGroupControl and remove the h3? I wonder why we need to hide 'Configure', and if we do, why does it need to be in the label as well? 🤔 Does it add much value in terms of accessibility?
And another h3 is added for 'Submenus'. Would it make sense to use BaseControl.VisualLabel above the ToggleControl components? Or is there something else we'd use for just labels?
There was a problem hiding this comment.
would it make sense to remove the prop
hideLabelFromVisionfrom theToggleGroupControland remove the h3?
I think so! In this case I think it's actually suboptimal for screen reader users since the h3 and aria-label texts are so redundant.
And another h3 is added for 'Submenus'. Would it make sense to use
BaseControl.VisualLabelabove theToggleControlcomponents?
Sounds good to me. BaseControl.VisualLabel is fair game whenever you want something that always looks like the other control labels but is not semantically a control label. It is safer than relying on implicit cascading styles like we have here on all h3s in the sidebar 😅
brookewp
force-pushed
the
update/togglegroupcontrol-margin
branch
from
3315566 to
be948e2
Compare
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?
Adding new opt-in prop
__nextHasNoMarginBottomto usages ofToggleGroupControlin the Gutenberg codebase.Why?
Part of this project: #38730
The tl;dr is
BaseControlhas amargin-bottomwhich makes it difficult to reuse and results in inconsistent use.How?
By adding the prop
__nextHasNoMarginBottom.Additional Notes
Testing Instructions
Test in Block Editor:
SCALE_OPTIONS (dimension controls)
Test in Block Editor or Site Editor:
ChildLayoutEdit
DefaultLayoutInspectorControls
FlexLayoutJustifyContentControl & OverlayMenuPreview & stylingInspectorControls
--- Begin - Arrow changes ---
The following three components/blocks have the same change in spacing as described above:
PostNavigationLinkEdit
QueryPaginationArrowControls
Test in Site Editor:
CommentsPaginationArrowControls
--- End Arrow changes ---
ScreenHeadingColor
Test in Storybook:
ToggleGroupControl
ToolsPanel
ToolsPanel won't look visually different, but the changes are for
default,With Conditional Default Control, andWith Conditionally Rendered Control.