Cover: Set custom color when applying initial background image #22564
Cover: Set custom color when applying initial background image #22564
Conversation
|
Size Change: +2.23 kB (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
|
I'm noticing a bug where we need to update the color when changing/updating the background image. Will need to work on that logic next! |
|
Aww. It looks like |
|
@ItsJonQ: What about using Gradients? The dominant color npm library got a MIT license: |
|
Heya @strarsis , Thanks for the suggestions! I checked out the libraries. We wouldn't be able to use those as those are Thankfully, I was able to adjust the module to fit our requirements Update: I'm unsure about gradients for now 😊 |
|
Reminds me of https://github.com/mtias/tonesque :) |
|
@mtias Oh man. I recognize some of those RGB colour formulas 😂 (I worked on lower colour interpreting/parsing stuff in JS a couple of years ago) |
|
I like this exploration. I think it might also make sense to add a button / action to set it to "dominant color" if you have picked another one. cc @jasmussen |
@mtias OoOOooo! Interesting to see what @jasmussen has for design ideas! Note: The color extractor can actually grab a palette of colours! Not saying we have to use that feature. Just pointing that out, in case it sparks any ideas 😉 |
|
For whatever reason, I couldn't get this PR to work for me, no color is stolen by the thief: That said, and judging by your video, this is really really cool and I share Matías' excitement. Very first question: can we add text color to the cover block, and set that to dark or light depending on the luminosity of the background color eye-dropped? You'd still be able to override colors on a per-paragraph basis, or even unset the text color on the cover block. But it would help create a nice contrasty basic experience. Transversal, but related: this tool could theoretically help the block UI. We currently know whether a theme has a light or dark background because the theme can tell us, however even then we have cases where the background color is sub-optimal for the block UI. Like this blue group with a light-gray spacer inside: Back to the PR in question, this is so lovely, it makes the end result look much better. It reminds me of the "faded" filtered images that are popular on Instagram, but more than that it's just a better overlay with the text as a background. I'll put together a small design tool iteration for the cover block sidebar that includes a "pick dominant color" button — for the time being though, feel free to just go ahead and make that button if you can, because I agree with Matías, it'd be nice to be able to pick this after the fact too. I might want to go back to an old cover block I had and set this, or I might explore other colors and then want to go back to the auto-picked one. |
|
@jasmussen Thanks for the feedback!
Oh darn! Do you think you can forward me a link to that image? Probably worth test it (on my end) using the same one that's giving you issues.
You bet! I think that would be fun! Probably a little tricky... but worth trying!
I'll give this a shot too! Sounds exciting :D |
|
Very curious, for a moment I thought it was a missing npm install I did, but that didn't help. I still think it's possibly something on my end, but I still can't get it to work. The pictures I keep using are these: https://cloudup.com/cAYtklfVZtk
Not necessary for this PR at all, just an idea! |
| return null; | ||
| } | ||
|
|
||
| const mergedColors = [ ...customColors, ...colors ]; |
There was a problem hiding this comment.
Depending on how often PanelColorGradientSettingsInner re-renders as a user interacts with the block, might be good to:
| const mergedColors = [ ...customColors, ...colors ]; | |
| const mergedColors = useMemo( () => [ ...customColors, ...colors ], [ | |
| customColors, | |
| colors, | |
| ] ); | |
| ; |
Naturally, this supposes that references for customColors and colors are preserved when possible.
| }; | ||
|
|
||
| ColorThief.prototype.getImageData = function ( imageUrl, callback ) { | ||
| const xhr = new XMLHttpRequest(); |
There was a problem hiding this comment.
Tapping into getMedia could be good.
| name: __( 'Image dominant color' ), | ||
| slug: __( 'image-dominant-color' ), |
There was a problem hiding this comment.
Some context or translators: notes could be good for these.
| */ | ||
| import { noop } from 'lodash'; | ||
| import classnames from 'classnames'; | ||
| import FastAverageColor from 'fast-average-color'; |
There was a problem hiding this comment.
Hi @ItsJonQ, the cover block was already computing the color of an image using the FastAverageColor module. I think we should avoid using two different modules for the same task so I guess we should opt for one of the modules and update the code to use the chosen module.
There was a problem hiding this comment.
@jorgefilipecosta Oh! I wasn't aware of that. Thank you for pointing that out. I'll make an update
|
Closing this out due to inactivity :) |
|
@annezazu I'd still love to try something like this. Can we transfer it to an issue? |
|
Done :) |




Description
This update adds an enhancement to the Cover block for background images. When an image is first set, it extracts and the primary color of the image and applies it as a custom background color.
This is achieved by using a library color-thief (2.6 kb gzipped), which leverages
<Canvas />for image parsing and color picking.Here is a video demo of it working:
https://d.pr/v/f2flil
Here's the difference:
How has this been tested?
Tested locally in Gutenberg
npm installnpm run devTypes of changes
useColorExtracthook from@wordpress/components, which handles the responsibility for image rendering/color extractionChecklist:
Resolves comment in:
#16479 (comment)