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/gallery block caption #17101
Add/gallery block caption #17101
Conversation
5da8501
to
078af70
Compare
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.
Left some minor comments, looks good otherwise.
| @@ -12,6 +12,11 @@ ul.wp-block-gallery { | |||
| } | |||
| } | |||
|
|
|||
| // need to override default editor ul styles | |||
| .blocks-gallery-grid.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.
Why twice?
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 left the comment above in an attempt to clarify, but perhaps it should be more explicit. I needed to override styles that are set for all ul in the editor, here:

I like this technique of duplicating the selector to increase specificity because it makes it clear that there is no other reason for use of more than one selector. Chaining two different selectors or using a parent selector might be necessary to target a particular element, but chaining the same selector twice can only be used for specificity increase, so if we revisit this later and find that the style being overridden is gone, we'll know it's safe to remove the extra selector 🙂
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.
But when does .blocks-gallery-grid.blocks-gallery-grid occur? This means an element will have the class twice?
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.
No, the element only needs to have the class once. Chaining the same class two or more times together will only increase specificity for that rule. It'll still apply to any element that has that class on it.
| { images.map( ( image ) => { | ||
| let href; | ||
| <figure> | ||
| <ul className={ `blocks-gallery-grid columns-${ columns } ${ imageCrop ? 'is-cropped' : '' }` }> |
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.
Why add an extra class here? Why not write wp-block-gallery ul to select it?
Any reason the is-cropped class can't be moved to the parent element?
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's always better to target the specific element styles are being applied to with a classname. Using .className element selectors will make things messy if we ever need to add another element with a different purpose to the component. I know there are quite a few existing instances of element selectors in this codebase, but I'd like to propose we move away from that. Ideally, every element that requires CSS should have its own classname; it'll save us a lot of grief in the long run.
No reason is-cropped can't move; I left it there along with the other gallery-related classes like columns and align, but now I see align at least should be applied to the outer wrapper so might as well move the whole lot.
| @@ -1,8 +1,10 @@ | |||
| .wp-block-gallery { | |||
| .wp-block-gallery, | |||
| .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.
This seems a bit strange to me as it will duplicate all the nested rules, even the ones targeting child elements. Could it be separated with only the necessary rules added?
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 I remove all the styles from wp-block-gallery it breaks the deprecated instances of the block. Not sure if there's any other way around this issue.
|
There's an e2e test failure with the demo content. |
b2d23eb
to
0641431
Compare
This reverts commit f4f8ba9.
79555cb
to
2d43726
Compare
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.
Looks good, just that question about galleryCaptionFocused that it'd be good to understand more about.
| @@ -238,6 +249,11 @@ class GalleryEdit extends Component { | |||
| captionSelected: false, | |||
| } ); | |||
| } | |||
| if ( ! this.props.isSelected && prevProps.isSelected && this.state.galleryCaptionFocused ) { | |||
| this.setState( { | |||
| galleryCaptionFocused: false, | |||
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 looks like some things have been refactored in this pr and I now can't see where galleryCaptionFocused is ever set to true. Maybe it and reference to it can be removed.
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, well spotted. Removed the state altogether.
| value={ caption } | ||
| unstableOnFocus={ this.onFocusGalleryCaption } | ||
| onChange={ ( value ) => setAttributes( { caption: value } ) } | ||
| isSelected={ this.state.galleryCaptionFocused } |
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.
Related to the previous comment, I wonder how this could ever be true.
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 know this one wasn't straightforward, great work here @tellthemachines!
|
It looks like block alignment might not have been handled by this PR: #17584 |
* Basic gallery caption. * add block deprecation * Regenerate test fixtures and fix failures * e2e snapshot update * Fix editor styles * Fix block transforms e2e * Workaround for failing tests * Undo package-lock changes * Revert "Undo package-lock changes" This reverts commit f4f8ba9. * Fix messed up styles. * Try to fix package-lock issue _again_ * Addressed design feedback. * Addressed previous PR feedback * Addressed latest PR feedback * Update post content and improve selectors * Change selectors for captions. * Change selectors and focus behaviour. * Update fixture. * Update demo post content again. * Update e2e snapshots * Redo snapshots again. * Change conditional hiding on empty/unselected * Remove unnecessary local state
Description
This is an updated version of #17001 which I closed due to rebase gone wrong. I have addressed all feedback from #17001 except for @talldan's request to add an e2e test for the block as I'm not sure how to add an image to a block in an e2e test. There are no image-containing blocks being tested atm so no previous examples. Would love some input on this!
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: