Repository navigation
Add/block width constraint notice - #82607
Conversation
jasmussen
added
[Type] Enhancement
|
The off Notice colour may be fixed by #82591. |
🤖 PR meta 🤖🎉 PropsIf you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. Props Bot commandsYou can trigger Props Bot actions by commenting on this PR:
Updated as activity occurs, without notifying anyone named here. Add the 📦 Bundle sizeSize Change: +286 B (0%) Total Size: 9.07 MB 📦 View Changed
⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
🏁 Flaky testsSome tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information. Custom Completer: should allow newlines after multiple option completions in
|
|
Thank you for digging into this tasks! The alignment controls are tricky to get right and they can be quite confusing to work with and to understand what is and isn't available. For this particular PR, I think the notice is way too prominent. If you're simply working with regular content blocks within a group that doesn't allow full and wide alignments, then every time you add or work with a block you have to scroll past a large notice in the sidebar to get to common controls for, say, picking a text color or adjusting font size, or adding a background color. E.g. here's how a heading block looks on a common laptop screen size where the design tools are nearly entirely hidden because of the notice taking up a lot of room: 
It also isn't clear to me why we'd want this notice to show in the right-hand sidebar when the user controls alignments from within the block toolbar. Is there an approach we can take that keeps the information we're communicating with the control instead? I.e. I like what you're doing in #82600 which shows the options as "not available" in the dropdown. What if we had a Tooltip on the disabled controls that explains "The Group around this block limits its width", so we then don't need to have this notice in the sidebar? |
This kind of thing makes sense to me in terms of being contextual to when the user is trying to use the alignments... But I do like the idea of there being a CTA/Button/Action which takes them to the parent container/pattern/whatever to change the layout settings there... |
10ba868 to
aa1d106
Compare
|
Good feedback, all. Based on the feedback, and because the actual problem that this PR aims to solve relates primarily to the alignments dropdown, I went ahead and moved something to the dropdown itself, like this: 
It doesn't look ideal with longer help text. But not terrible. What do you think? |
|
Noting that I changed the base of this branch from trunk to add/block-width-constraint-diagnostic, as the latter (which is PR #82600) is required for this PR. 82600 can either land first, or we can merge this one into the latter, whichever is better. |
|
It is indeed, though the notice is no longer used in this particular branch. I've others that still use it though, where it's fixed. Thanks. |
I like general approach of moving the notice to the bottom of the dropdown. Something about the specific wording doesn't feel right to me - but I'm trying to place it... I wonder if there is a way to word more like your original proposed notice from the sidebar? Something like "This block's alignment settings are limited by its parent" Select parent block/group/whatever |
Looking much better to me, and in practice using the control it feels really nice having a button right next to the alignment controls to go to where you can make the change. As a general idea, it seems to scale nicely to editing templates, too, in your other PR that builds on this (#82675).
So yes, overall I'm liking this direction! Wording is tricky, the help text needs to be very short, and I kind of wonder if the helps text should explain "it limits the block's width" or be context for the action, i.e. "to enable other alignments" 🤔. But "it limits the block's width" is probably fine to go on with. Something else this makes me think is that if this feature is really useful, it probably highlights that the parent selection button in the block toolbar might not be clear to users. That's a different problem than giving tactile immediate control next to the alignment controls, but being able to navigate up the block hierarchy is such an important part of working in the block editor, I'm curious how we can make that easier for folks. That said, don't want to derail the discussion here! TL;DR I think you've got a good direction here 👍 |
aa1d106 to
ce7f80e
Compare
|
Wonderful feedback, all. I've addressed the rebase conflicts, and now the wording is: Select Group What do you think? |
I'm trying not to be pedantic - but do we refer to blocks with 'its' elsewhere in notices or labels? If so - then this is great! It's just not something I've noticed before. Otherwise - does something like 'Group layout limits widths' or '[Block] layout limits widths'. Or 'Parent Block limits widths' to be clear it is the parent block? |
|
Parent block isn't ideal because it could be an ancestor. I agree on "Its" being odd. But it does keep the help text on one line, as soon as it's three lines, and because the icon is vertically centred, the entire menu item starts to look slightly odd. Not the end of the world, but if we're going to go three lines, we might as well be slightly more verbose than what I've been aiming for here. How about: "A layout limits widths". Or "An ancestors layout limits widths" (that would span 3 lines). Or "Block layout limits widths"? Tricky! |
|
Words are hard 🤣. Does 'containing' cover both the cases of Parent and Ancestor? "Containing block limits widths' ? |
|
Yes, or "An ancestor". I like the idea of layout being a word that's part of it, though, as that's the panel you should look for to fix. |
|
I wonder: can we/should we ship what exists, and then follow up if someone else mentions the weird wording? |
|
Good call. Shipping something and iterating (if needed) seems like a win
…On Thu, 10 Sep 2026 at 22:29, Joen A. ***@***.***> wrote:
*jasmussen* left a comment (WordPress/gutenberg#82607)
<#82607 (comment)>
I wonder: can we/should we ship what exists, and then follow up if someone
else mentions the weird wording?
—
Reply to this email directly, view it on GitHub
<#82607?email_source=notifications&email_token=AAOBZO5YJYSSS7ELQ5X6NUL5OKNAZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRRHA3DONRUG442M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5618676479>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOBZOYMZHS5CK6G25Y5CTD5OKNAZAVCNFSNUABEKJSXA33TNF2G64TZHM4DAOBWGI2TQNB3JFZXG5LFHM2TGOBYGYYTKOBTHCQXMAQ>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AAOBZOYEFAASJ4T5AZY2L535OKNAZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRRHA3DONRUG442M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y>
and Android
<https://github.com/notifications/mobile/android/AAOBZO5N25UD4SVMKQWCSLT5OKNAZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRRHA3DONRUG442M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>.
Download it today!
You are receiving this because you commented.Message ID:
***@***.***>
|
ce7f80e to
66ffe8d
Compare
|
Sorry to get to this so late. I have a couple of thoughts here:
|
|
Really good feedback, thank you. For one I wanted to mention that I'm also trying to approach the problem in the opposite direction, parent to child, here. I know Andrew also had some thoughts, and in the end I will defer to the both of you on what, here (if anything), can ship, as we already shipped some other improvements and more are pending in #82673. That's also my blanket permission to push any changes if improvements occur to you. |
|
This is now dependant on #83955. |
66ffe8d to
64fbc13
Compare
|
Rebased, migrated to typescript. Same behaviour. No behaviour change. Worth noting, CC @tellthemachines: following the spacing question on #82600, the accessible name of a menu item with info now renders glued: "Select GroupIts layout limits widths", where an assertion expecting a space passed before the migration. Something in components or dom-accessibility-api changed. The browser reasoning still holds (the info wrapper is display: flex, which blockifies the spans so the name computation separates them), but this is a second sign that jsdom can’t evidence that either way, so the test here asserts the description renders inside the action item rather than depending on the separator. |
|
Quick test run: we still have the problem of blocks that don't expose layout tools (Details, Quote, Accordion). For blocks inside those, pointing to the container is confusing because you can't change anything on it: 
|
|
I just tried out a solution to the problem from my comment above in #85421 |
The alignment area migrated to TypeScript after this branch was opened, so the change is re-applied onto the new files rather than rebased: git cannot follow align.jsx to align.tsx through a rewrite. Adds a BlockAlignmentConstraint type and clientId to AlignEditProps. No behaviour change from the previous revision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two type errors from the TypeScript port: - `useBlockDisplayInformation` is typed to take a `string`, but the parent client ID is `string | null`. The hook already guards an empty ID and returns `null`, so pass `''` when there is no reachable parent. - The hook returned `null` where `BlockAlignmentControl` accepts `BlockAlignmentConstraint | undefined`. Return `undefined` instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org>
2f2fd1a to
a63bbe3
Compare
| ! rootClientId || | ||
| getBlockEditingMode( rootClientId ) !== 'default' | ||
| ) { | ||
| return null; |
There was a problem hiding this comment.
we could probably return null earlier here if there are no enabled controls. I can push a change for this!
There was a problem hiding this comment.
Done; behaviour should be unchanged.
|
Let's try this. |
|
Thank you all for the substantial help! |
|
Nice work landing this, and thanks for finishing it off @tellthemachines! 🎉 |
What?
Builds on #82600, and part of the width guidance discussed in #79285.
Adds a button in the alignment dropdown to select the block that affects a child block's width.
Before:
After:
Previous iteration
When a block's parent layout withholds wide and full alignments, the block inspector now says which block is responsible and offers to select it.
#82600 made the alignment menu admit that Wide and Full are unavailable. This says why.
Note: There appears to be something wrong with the Notice: it's now showing a grey background in all variants. Not sure if this is intentional or not, but it seems wrong to me, as a single border feels insufficient to communicate the difference in notice type.
Also, added CSS for this one feels also wrong: it's not clear there's an alternative whe nusing the pre-tabs slot which renders flush against the inspector edges.
Spaceris blocked by the same lint rule as planned for deprecation, andStackfrom@wordpress/uionly exposesgap. Any recommendation on what we can do instead?Before:
After:
Why?
"Not available" answers half the question. The other half of where to change it and why, is hard to work out. Because the block responsible is often several steps away and looks like ordinary page content.
How?
Claude wrote this:
The block support already knows which alignments the layout withheld, from
useAlignmentMenuin #82600. This adds the other half: the parent that withheld them.getBlockRootClientId, and the notice renders into the existingBlockInspectorPreTabsSlot, directly below the "Edit original" button.default. In both, the constraint comes from outside the post — the template wrapped around the content — and there is no block on the page to select. Explaining that case needs the template's identity and an "Edit template" action, neither of whichblock-editorcan reach. It is a separate PR againstpackages/editor.Testing Instructions
Please also confirm it stays quiet where it should:
Testing Instructions for Keyboard
Use of AI Tools
Claude Opus 5.