Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#52260 closed defect (bug) (reported-upstream)

block button contained within cover - font colors

Reported by: megphillips91's profile megphillips91 Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.6
Component: Editor Keywords:
Focuses: Cc:


I understand that the cover block is assigning a color: #fff to the content contained within for accessibility. However, that is assuming many things that are not in fact good to assume.

  • Light colored backgrounds: For instance, if in the theme I add #eeeeee as a standard theme color and then assign it to the background color of a cover block the block is assigning a color which creates worse accessibility. I consider this to be a common use case as many sites use white background and light grey backgrounds to signal a change in section.
  • Buttons a:visited color: Furthermore, if I then create a button within that cover block there is no way for me to effectively control the color of the a:visited color based on the background color of the button itself.

It is a very common design pattern and widely accepted convention to create higher priority calls to action with dark or bright backgrounds and lower priority calls to action with lighter or no background. Therein, in this scenario I cannot correct the a:visited color for all buttons within my theme code and find a color that is accessible in both scenarios.

I propose to remove the color selection within the cover block itself and allow the user to determine the colors directly using the block settings and the theme developer the brevity to determine the defaults.

Thank you for your consideration.

Change History (6)

#1 @megphillips91
3 years ago

I suppose a user could assign a custom class within the advanced section of the block settings on the "buttons" parent container for priority buttons and using that class plus the background color on the button you CAN control the button font color, but in my opinion this is onerous and does not give the user an authentically "WYSIWYG" experience.

Last edited 3 years ago by megphillips91 (previous) (diff)

#2 @joyously
3 years ago

Maybe this should be an issue in the Gutenberg repository instead...
There are other issues already there, about removing all color styles from blocks, but they have not been acted on. (also any opinionated styles should be in the block's theme.css instead of its style.css, so that it can be easily removed)

#3 @megphillips91
3 years ago

@joyously wanna close this one and I can move it over and check in there - old habits. I only searched here. :) Sorry thanks for your time - and BTW - above brevity should be levity but I couldn't edit it for some reason after I hit add ticket ლ(ಠ_ಠლ)

#4 @megphillips91
3 years ago

  • Resolution set to invalid
  • Status changed from new to closed

#5 @megphillips91
3 years ago

I move it into the block directory on github

#6 @desrosj
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution changed from invalid to reported-upstream

Thanks again for this issue @megphillips91!

Just going to link your upstream ticket here for reference:

Note: See TracTickets for help on using tickets.