You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Style rules written into GO css prevent the user from choosing what color text goes e.g. on a button or inside a cover block.
I would expect a button with the class "has-tertiary-background-color" to inherit the tertiary background color with no change in text color, but when I set the BG to "tertiary" the following rule is applied as well:
I don't understand why the heading color is applied so liberally, shouldn't it only apply to headings? And why add the second selector when the first one has already changed the color of the button -> anchor element?
Same with text in cover blocks where this rule overrides a color chosen from the palette :
.wp-block-cover.has-tertiary-background-color p {
color: var(--go--color--primary);
}
Same thing - I don't understand why this is desired behaviour, and it surely shouldn't prevent changing text color via the palette.
As I don't understand the intended behaviour I can only suggest these rules are removed. Please correct me if I'm missing something.
The main reason I have set the tertiary color to apply a heading text color, is that the core style application is white, regardless of the background color applied. There does need to be better checks for when colors are applied to text within the blocks.
Style rules written into GO css prevent the user from choosing what color text goes e.g. on a
button
or inside acover
block.I would expect a button with the class "has-tertiary-background-color" to inherit the tertiary background color with no change in text color, but when I set the BG to "tertiary" the following rule is applied as well:
I don't understand why the heading color is applied so liberally, shouldn't it only apply to headings? And why add the second selector when the first one has already changed the color of the button -> anchor element?
Same with text in cover blocks where this rule overrides a color chosen from the palette :
Same thing - I don't understand why this is desired behaviour, and it surely shouldn't prevent changing text color via the palette.
As I don't understand the intended behaviour I can only suggest these rules are removed. Please correct me if I'm missing something.
Demo here https://movema.cloudaccess.host/test-page-for-go-tertiary-issues
Apologies for the nasty green-on-red!
Screenshot: editor (good)
Screenshot: outcome (confusing)
The text was updated successfully, but these errors were encountered: