-
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
Block Bindings: Fix label in pattern overrides #65302
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -30,18 +30,21 @@ export const settings = { | |||||||||||||||||||||
__experimentalLabel( attributes, { context } ) { | ||||||||||||||||||||||
const customName = attributes?.metadata?.name; | ||||||||||||||||||||||
|
||||||||||||||||||||||
if ( context === 'list-view' && customName ) { | ||||||||||||||||||||||
return customName; | ||||||||||||||||||||||
} | ||||||||||||||||||||||
|
||||||||||||||||||||||
if ( context === 'accessibility' ) { | ||||||||||||||||||||||
if ( customName ) { | ||||||||||||||||||||||
if ( | ||||||||||||||||||||||
customName && | ||||||||||||||||||||||
! attributes?.metadata?.bindings?.source === 'pattern/overrides' | ||||||||||||||||||||||
) { | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like the hardcoding of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the name is wrong ('core/pattern-overrides'). On a different note, I'm wondering whether this is a pattern override specific issue. The problem seems to be that when a paragraph is named, the name is announced instead of the content. It is perhaps worse for pattern overrides since all editable blocks will be named, but the problem still exists for regular paragraphs too. Either way it seems like screenreader users might miss valuable context (if the name isn't announced a user might wonder why given they explicitly gave it the name). A compromize could be to announce both the name and the content if it can be made clear enough. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is a good point. I think announcing both the name and content is the right approach. I can implement that change as part of this PR if we decide to move forward with it, or create an issue and perhaps handle in a separate PR if not. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This particular line refers to the binding source, which is defined here:
|
||||||||||||||||||||||
return customName; | ||||||||||||||||||||||
} | ||||||||||||||||||||||
|
||||||||||||||||||||||
const { content } = attributes; | ||||||||||||||||||||||
return ! content || content.length === 0 ? __( 'Empty' ) : content; | ||||||||||||||||||||||
} | ||||||||||||||||||||||
|
||||||||||||||||||||||
if ( context === 'list-view' && customName ) { | ||||||||||||||||||||||
return customName; | ||||||||||||||||||||||
} | ||||||||||||||||||||||
}, | ||||||||||||||||||||||
transforms, | ||||||||||||||||||||||
deprecated, | ||||||||||||||||||||||
|
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 doesn't seem like the most elegant solution to me. Is there another way to get the pattern attributes other than to look up the values manually and insert them like this?
Also, I'm unsure if we can assume that the first parent will be the pattern. Gutenberg seems to flatten the hierarchy of blocks in pattern instances, so this appears to work, but it'd be great to additional insight on this 🙏
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.
Yep I think you'll need to iterate through all block parents to find the
core/block
block. Also need to take into account a pattern within a nested pattern, and ensure you find the nearest one.There's a few places with this kind of code 😅
Just to note, this component would be removed if #65204 lands as is.