-
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
Add/caption for gallery block #17001
Conversation
package-lock.json
Outdated
@@ -7708,7 +7708,7 @@ | |||
"dependencies": { | |||
"minimist": { | |||
"version": "1.2.0", | |||
"resolved": false, | |||
"resolved": "", |
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 is surprising to see those changes.
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.
Oh bugger, shouldn't have committed this file. I keep getting this diff when I run npm install
even though I'm updating my npm version regularly 😩
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.
So reverting this file to its previous state before my commit doesn't work because it's been updated in master in the meantime. I tried nvm install --latest-npm
followed by npm install
and even npm run docs:build
on my local branch and there's no diff. Is it possible the current package-lock
on master wasn't generated with the latest npm?
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.
Yes, if there is new npm version, and they changed something then we will have to patch master
.
@@ -48,6 +48,11 @@ | |||
"columns": { | |||
"type": "number" | |||
}, | |||
"galleryCaption": { |
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.
Can it be caption
? It seems repetitive to include gallery as a prefix.
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.
The problem is that gallery images already have caption
s so it's less confusing if this one has a name that clearly indicates what it is a caption of.
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.
It depends on where you look at, I found it confusing when seeing it in the attributes
section block.json
file. Gallery itself can have only one caption. In the future, we might refactor this block and convert all images to nested blocks at the issue you pointed out would solve on its own. You can always alias the caption of an image if it has to be referenced in the same scope or extract the image logic to its own component.
</> | ||
); | ||
|
||
if ( galleryCaption ) { |
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.
If there is no change in the markup for the case when we don't provide the caption, do we really need to build all deprecation story? It seems like it should out of the box if the caption is not provided. I don't see any changes in the deprecated version serialized in the fixtures folder (input is almost identical to the output when you ignore whitespaces).
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.
I'm not sure! The markup of the new version is the same but there's an added attribute. Happy to remove the deprecation if it's not needed though 🙂
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.
You would have to tests it but I know we had similar cases in the past and we didn't have to build deprecation logic when new optional HTML attributes were added or wrapped with optional HTML tags. It seems like this is the case here.
@@ -1,8 +1,10 @@ | |||
.wp-block-gallery { | |||
.wp-block-gallery, |
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.
In the case where Gallery block has a caption then it produces HTML where .blocks-gallery-grid
is enclosed in .wp-block-gallery
, won't it cause any issues?
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.
I've tested this and added an override on the editor side for figure.wp-block-gallery
to display:block
as the flex display was causing issues. It seems to be fine on the post rendering side so far, but I can always add that override globally if needed. The other styles are pretty harmless.
@@ -147,4 +149,11 @@ | |||
justify-content: center; | |||
} | |||
} | |||
|
|||
+ figcaption { |
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.
Where those styles should get applied? To the gallery's caption only? If yes, then it should be placed outside of .blocks-gallery-grid
.
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.
Yup these are for the gallery caption only, and the problem here is that the RichText component won't allow me to add a classname to that element. Because there can potentially be other figcaption
s inside the gallery, I'm targeting this one as .blocks-gallery-grid + figcaption
. The plus sign between the two selectors makes it target only the figcaption that is the immediate next sibling to .blocks-gallery-grid
.
1d0d568
to
4a79b86
Compare
This reverts commit f4f8ba9.
* Update github action exit codes * Remove Filter Opened from github actions
* Extract caption component * Use caption component for video * Move Caption to block-editor for mobile tests This move avoids a dependency issue that was causing the mobile tests to fail due to the Caption component's import of RichText from the block-editor package. * Pass onBlur to Caption component * Connect Caption component to store
This reverts commit 9a0876c.
This reverts commit 9a0876c.
…gutenberg into add/caption-for-gallery-block
Closing this PR because I messed up the rebase, will have updated one up soon. |
Description
Added a caption for the gallery block. This caption refers to the gallery as a whole, so semantically it works by wrapping the whole gallery block in a
<figure>
element and adding a<figcaption>
with the caption inside.How has this been tested?
Tested locally, checked if previously created galleries still work, ran unit tests, updated fixtures.
Note: The caption on the editor side will likely have the same accessibility issues as the image caption. These are discussed in detail in @talldan's table caption PR
I don't believe we have agreed on the best way forward for that, so it might be best to address it as a separate PR.
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: