-
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
Separator: disable the contrastChecker via block.json #43357
Conversation
Size Change: +1.54 kB (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
@@ -292,7 +292,7 @@ const getLinkColorFromAttributeValue = ( colors, value ) => { | |||
export function ColorEdit( props ) { | |||
const { name: blockName, attributes } = props; | |||
// Some color settings have a special handling for deprecated flags in `useSetting`, | |||
// so we can't unwrap them by doing const { ... } = useSetting('color') | |||
// so we can't unwrap them by doing conwst { ... } = useSetting('color') |
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 fact, we can't destructure any return values with conwst { ... }
, which is an oversight on the part of the javascript technical committee I think 😄
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'll propose it at the next mweeting. 😄
Platform.OS === 'web' && ! gradient && ! style?.color?.gradient; | ||
|
||
const defaultColorControls = getBlockSupport( props.name, [ | ||
COLOR_SUPPORT_KEY, | ||
'__experimentalDefaultControls', | ||
] ); | ||
|
||
const enableContrastChecking = | ||
isWebAndColorNotGradient && | ||
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.
Do we need to default support to true somehow, or switch this to a ! false ===
check as currently when I test this the check doesn't work for any blocks that don't have this set, eg. paragraph block, and it might be easier to turn it off when not needed than toggle it on everywhere it is needed?
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.
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.
Fixed with comment added. 🙇
…erimentalCheckContrast === 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.
Tested well for me:
✅ Separator block showed no contrast warning
✅ Other blocks like Group, Paragraph, etc. showed warning as expected if there was low contrast between text and background
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.
Is there a reason for making this option experimental?
From what you've shown here and in the linked PR comments I think
- the use-case is clear—there are a number of blocks that either don't need the contrast checker or implement their own—and
- not all blocks using the support manually add the UI controls, so the primary way the controls can be configured is through options in block.json.
I think this could be a stable API right away unless you have reason to expect it will need to change in the future.
@ajlende Thanks for chiming in. It's a good question. I'd originally made it non experimental, but wasn't sure to be perfectly honest so erred on the side of underscore. To add to your points, the use case is very specific to color blocks supports so it doesn't have the footprint of other experimental controls, e.g., |
Added block.json schema docs
@glendaviesnz What do you think? I've pushed a change to remove the experimental prefix. Do you see any issues here, and think it's in line with https://make.wordpress.org/core/2022/08/10/proposal-stop-merging-experimental-apis-from-gutenberg-to-wordpress-core/ ? |
Makes sense, and just retested and still working as expected. |
Thanks folks! 🙇 This also means that can move forward. |
What and How?
This PR adds a property
__experimentalCheckContrast
to a block.json'ssupports.color
to disable the contrastChecker in the UI.Context:
Why?
There are scenarios where the contrast checker is not appropriate (Separator block), or a block has its own color implementation in combination with color block supports (Social links block).
Testing Instructions
Add a separator block and change the color so that it's the same or similar to the background.
Here is some dummy HTML:
Make sure your theme has a white background for the above test code.
Before:
After: