-
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 API to configure icon colors #7068
Conversation
blocks/api/utils.js
Outdated
* | ||
* @type {Object} | ||
*/ | ||
const ICON_COLORS = [ '#191e23', '#fefdfe', '#7e70af' ]; |
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.
Minor: By convention, I've come to expect all module constants to be defined at the top of the file, immediately following dependencies. Should we consider that here?
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 do these colors come from? Are we duplicating from stylesheet variables?
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 colors are from the stylesheet variables $dark-gray-900 and $light-gray-100. Before we used a scss importer but with our divisions in packages I'm not certain if this is something we should pursue now.
* @property {string} category Category classification of block, | ||
* impacting where block is shown in | ||
* inserter results. | ||
* @property {(Object|string|WPElement)} icon Slug of the Dashicon to be shown |
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.
Thinking at some point we might just want to @typedef
a WPIcon
, since it's used pretty broadly now.
http://usejsdoc.org/tags-typedef.html
Related: #5965 (comment) (cc @ajitbohra)
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, here what we have is (Object|WPIcon) I think when we have generic Icon component in @wordpress/components we should create the type there so the type can be imported from this module to other modules.
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.
Note that the plan is to move away from UI icons for blocks and into custom svgs, so this will become more of a fallback.
blocks/api/utils.js
Outdated
icon = { src: icon }; | ||
} | ||
|
||
if ( icon.backgroundColor && ( ! icon.iconColor || ! icon.shadowColor ) ) { |
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.
Should we allow shadow color to be customizable?
Otherwise, we could simplify this to "background" and "foreground". icon.iconColor
sounds a bit redundant.
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 followed this idea 👍
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.
Otherwise, we could simplify this to "background" and "foreground".
icon.iconColor
sounds a bit redundant.
In retrospect, we should have done the same for shadowColor
as well. Now we have some inconsistency with "Color
" as only a suffix for shadow, when it's of the same value type as foreground
and background
(a hex string).
If we care enough, we could soft-deprecate this via something like:
const icon = { ... };
Object.defineProperty( icon, 'shadowColor', {
get() {
deprecated( ... );
return icon.shadow;
},
} );
c935411
to
34707de
Compare
9c476e6
to
baa3e0f
Compare
This PR was updated in rebased taking into account the changes in #7074. |
blocks/api/utils.js
Outdated
*/ | ||
export function normalizeIconObject( icon ) { | ||
if ( ! icon ) { | ||
icon = { src: 'block-default' }; |
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 we just return?
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.
Updated 👍
blocks/api/utils.js
Outdated
icon = { src: 'block-default' }; | ||
} | ||
if ( isString( icon ) || icon instanceof Component ) { | ||
icon = { src: icon }; |
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.
Same
Should we update the Block API docs? |
Not sure, what I'm doing wrong, the colors are not showing up for me. (using the gist) |
baa3e0f
to
81e037b
Compare
Hi @youknowriad thank you for the review!
I expanded the docs to include this use case.
I'm sorry I missed an update to the gist, with changes applied during the revisions. The Gist was updated and things should work now. |
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.
LGTM 👍
Re Docs: Actually, I was referring to these docs https://wordpress.org/gutenberg/handbook/block-api/#icon-optional
81e037b
to
11a0ace
Compare
Re Docs: Actually, I was referring to these docs wordpress.org/gutenberg/handbook/block-api/#icon-optional
Hi @karmatosed could we have a check regarding the design and UX? |
Looks good to me, used it to create screenshots for the release post. |
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 am approving as this does work. I will add a note though we need to do something about checking accessibility issues such as contrast. We can also easily now have a white background with white icon. That's not great and something maybe we should check to fix.
I've made a PR for the documentation to add an example with foreground color and shadow color. By the way, shadowColor doesn't seems to work for me as shown in the screenshot. Any idea why? Also, the fallback with most readable for the foreground color is not always perfect : sometimes with a dark color, the svg color stays black. |
Oh sorry, I just figured out that shadowColor is only for parent block with a stack style. To be CSS consistent, how about use color instead of foreground ? |
Can you clarify what's meant by consistency here? |
Description
This PR allows the icon to configure 3 colors: backgroundColor, iconColor, shadowColor.
If iconColor and shadowColor are not passed they are automatically computed from the
backgroundColor.
This colors right now are being used in the inserter. Shadow color is only used in blocks that have children.
Some discussion points:
Should we use this colors in other places?
Should we try another way for blocks to configure this colors?
Closes: #6998
How has this been tested?
This change is very risky as we are changing how an icon is represented, try to do some smoke testing around Gutenberg in places where we show block icons and see things work as expected.
Register some test blocks that make sure colors work as expected. Test blocks available in https://gist.github.com/jorgefilipecosta/2dd281f9f5f078258f7c8d4ba4cc34cd ( can be pasted in developer console).
Screeshots: