-
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
Cover block: Restore default overlay background #26569
Conversation
The default Cover block overlay background was removed. This changed the style of existing blocks on existing sites. Restore the default background in such a way that it does not conflict with theme-provided background-color styles and there is no need to artificially add extra specificity. Fix regression: #26545
This is working well for me: I dig this approach. It seems to thread the needle! Curious about @jorgefilipecosta and @nosolosw but otherwise, 🚢 |
Size Change: +119 B (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
Nice @sirreal. I'd tried the same approach and found it workable. The only thing this leaves as questionable is the opacity control now doesn't show for the pseudo default black color. |
Fair point, but potentially something that global styles can augment. |
&.has-background-dim:not([class*="-background-color"]) { | ||
background-color: $black; | ||
} |
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 think it'd be a (likely imperceptible) performance optimization to do this instead:
:not([class*="-background-color"]) {
&.wp-block-cover-image,
&.wp-block-cover {
background-color: $black;
}
}
Except that goes as a separate top-level block (not nested). The gist is the slow selector is [class*="-background-color"])
goes on the left of simpler class selectors so that the browser can more quickly determine when the selector doesn't apply. I didn't include in the selector has-background-dim
because the cover block always has it. But maybe that wasn't the case for the older wp-block-cover-image
so it might be safer to include.
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.
Do you feel strongly about this? Your suggestion does likely have better performance characteristics but I also suspect they're imperceptible. I'd prefer to keep the rule in the same SASS wrapper block and next to the inherit
rules. It's a coherent place and easy to see.
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 strong feelings on that.
It's a simple change to restore the older logic for when the opacity control displays.
On this line, change canDim to !! url
|
Reverts part of #26133
👍 Thanks, I've pushed a commit with that change. Essentially, this is a rollback of part of #26133, right? |
This reverts commit 6c810e3.
On second thought, I've reverted the opacity controls changes. I'd like to keep this laser focused on shipping a fix for sites that are experiencing issues in production. I'd expect a Gutenberg 9.2 patch release to include this fix. There is time before the next Gutenberg release to include related fixes or to clean up the opacity controls for WordPress 5.6, but those are beyond the critical regression this seeks to address. I'd appreciate if folks can review this with that mindset 🙇 |
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 regression is fixed with this change 👍 I verified covers without explicit overlay color with and without explicit opacities are kept as before.
Although not directed related to this PR, why do we allow opacity when we have an explicit overlay color but not with the default color? It feels strange that a user before changed an opacity and after an update can not change the value that was previously changed and is forced to keep the same value. I can even go to the code editor and change the opacity value and things work. Why remove the UI for that case?
I've created #26625 to restore the opacity controls as suggested. |
* Restore default Cover overlay background The default Cover block overlay background was removed. This changed the style of existing blocks on existing sites. Restore the default background in such a way that it does not conflict with theme-provided background-color styles and there is no need to artificially add extra specificity. Fix regression: #26545
* Cover block: Restore default overlay background (#26569) * Restore default Cover overlay background The default Cover block overlay background was removed. This changed the style of existing blocks on existing sites. Restore the default background in such a way that it does not conflict with theme-provided background-color styles and there is no need to artificially add extra specificity. Fix regression: #26545 * Limit the interface skeleton to a max width of 100% to prevent some blocks managing to exceed the width (#26552) * Cover Block: Restore opacity controls (#26625) * Fix image block centering when resizing to a smaller size (#26376) * Fix image block centering when resizing to a smaller size * Revert previous 100% width fix * Remove display: table when image block is resized to avoid centering of block * Match frontend classes for alignment in editor * Gallery: Remove caption fallback for alt attribute (#26676) * Fix quote block default alignment (#26680) * Gallery: Remove obsolete deprecation entry (#26736) * Do not apply text color if it is being overriden (#24626) * Fix: Preset colors don't work on button block style outline (#26707) * Tests: Add fixture for Column deprecation (#26774) * Fix/column width units (#26757) * Fix issues with different units in column widths * Columns with fixed width should keep width on recalculation * Address review feedback * fix undefined index notice in Social Link Block (#25663) * fix undefined index notice * use isset instead of array_key_exists check * Update packages/block-library/src/social-link/index.php Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl> Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl> * Adds in missing styling for toolbar when using text-only setting (#26769) * Adds in missing styling for toolbar when using text-only setting * Increases margin * Moves style to correct file * Inserter: Fix 'Browse All' in Quick Inserter (#26443) * Inserter: Fix 'Browse All' in Quick Inserter Maintain the insertion point in @wordpress/block-editor state when moving from the Quick Inserter to the Inserter. This fixes a bug where the insertion point is wrong after clicking a block appender and selecting 'Browse All'. Care is taken to not regress a previous bug where the insertion point is wrong after clicking an inline insertion button and selecting 'Browse ALl'. * Inserter: Fix typo Co-authored-by: Daniel Richards <daniel.richards@automattic.com> * Call getBlockInsertionPoint once * Add useSelect dependencies * Make setInsertionPoint unstable * Avoid setting `isVisible` state when `SET_INSERTION_POINT` is triggered * Make index required and clarify rootClientId usage * Split insertionPoint into two reducers * Fix getInsertionPoint selector that expects default state of reducer to be null * Avoid resetting insertionPoint state on HIDE_INSERTION_POINT Co-authored-by: Daniel Richards <daniel.richards@automattic.com> Co-authored-by: Jon Surrell <jon.surrell@automattic.com> Co-authored-by: Jacopo Tomasone <Copons@users.noreply.github.com> Co-authored-by: Daniel Richards <daniel.richards@automattic.com> Co-authored-by: Bernie Reiter <ockham@raz.or.at> Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl> Co-authored-by: Oliver Juhas <webmandesign@users.noreply.github.com> Co-authored-by: Jorge Costa <jorge.costa@automattic.com> Co-authored-by: Fabian Kägy <mail@fabian-kaegy.de> Co-authored-by: Tammie Lister <tammie@automattic.com> Co-authored-by: Robert Anderson <robert@noisysocks.com>
Description
The default Cover block overlay background was removed. This changed the
style of existing blocks on existing sites.
Restore the default background in such a way that it does not conflict
with theme-provided background-color styles and there is no need to
artificially add extra specificity.
Fixes #26545
Closes #26564 (superseded)
How has this been tested?
Try to reproduce this issue: #26545
Be sure that the issue described in #25290 is no longer present.
There appear to be problems with the Docker registry so I'm unable to easily test this with wp-env. I did manually apply the changes via developer tools and they seem to fix the issue.
Types of changes
Bug fix
Fix a regression where the Cover block lost its default background overlay color (#26545).