Skip to content
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

Setting a link color on a parent block overrides icon and button colors #33437

Closed
ryelle opened this issue Jul 14, 2021 · 4 comments · Fixed by #34689
Closed

Setting a link color on a parent block overrides icon and button colors #33437

ryelle opened this issue Jul 14, 2021 · 4 comments · Fixed by #34689
Assignees
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@ryelle
Copy link
Contributor

ryelle commented Jul 14, 2021

Description

Setting a link color on a parent block overrides icon and button colors, but only on the frontend of the site.

Initially reported in WordPress/pattern-directory#235, can be seen (for now) on these patterns:

Step-by-step reproduction instructions

  1. Add a group block, with some content including a link and a button
  2. Set a link color on the group
  3. Set a different text color on the button
  4. The custom button color works in the editor ✅
  5. Save, view on the frontend
  6. The button text color is now using the link color ❌

Also happens with social icons.

Expected behaviour

The editor behavior seems correct - the button text should use the set text color.

Actual behaviour

The injected style in .wp-elements-<uuid> overrides the button's inline style, because it's set to !important.

Screenshots or screen recording (optional)

Editor Frontend
Screen Shot 2021-07-14 at 6 22 55 PM Screen Shot 2021-07-14 at 6 23 12 PM

Code snippet (optional)

Block code
<!-- wp:group {"style":{"elements":{"link":{"color":{"text":"var:preset|color|white"}}}}} -->
<div class="wp-block-group has-link-color"><!-- wp:paragraph -->
<p>Start the group. <a href="https://wordpress.org" data-type="URL" data-id="https://wordpress.org">Link</a></p>
<!-- /wp:paragraph -->

<!-- wp:buttons -->
<div class="wp-block-buttons"><!-- wp:button {"backgroundColor":"yellow","textColor":"black"} -->
<div class="wp-block-button"><a class="wp-block-button__link has-black-color has-yellow-background-color has-text-color has-background" href="https://wordpress.org">Link Button</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons -->

<!-- wp:paragraph -->
<p>End group</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

WordPress information

  • WordPress version: 5.7.3-alpha
  • Gutenberg version: 11
  • Are all plugins except Gutenberg deactivated? No
  • Are you using a default theme (e.g. Twenty Twenty-One)? Yes, Twenty Twenty-One
@ryelle ryelle added [Type] Bug An existing feature does not function as intended Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json labels Jul 14, 2021
@richtabor
Copy link
Member

Came here to report the same issue.

@Sandstromer
Copy link

The "fix" for this is to add more !important rules to ensure the icon color and button text color display as intended.

However this would not be a proper fix as we then get into a seemingly never ending pathway of adding !important whenever new issues like this come up.
Have we already gone too far down this route? Is it too late to rethink the use of !important from the ground up?

@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Sep 9, 2021
@oandregal
Copy link
Member

oandregal commented Sep 9, 2021

I've got a potential fix at #34689 and would like help in testing it. Does the PR list all the use cases that we need to take care of?

@mkkeck
Copy link

mkkeck commented Sep 11, 2021

The "fix" for this is to add more !important rules to ensure the icon color and button text color display as intended.

That's not the perfect solution.
If there some !important used on nested selectors for example .foo .bar > a, perhaps the fix with !important still won't work.

However this would not be a proper fix as we then get into a seemingly never ending pathway of adding !important whenever new issues like this come up.

Yes, I call this the "hell of !important".

Have we already gone too far down this route? Is it too late to rethink the use of !important from the ground up?

Removing important on initial styles in core should help. See also #34575.

I've seen a css framework wich uses tons of classes for elements to adjust styles:

<style>
.border-color-blue ...
.text-color-blue ...
.bg-color-white ...
.text-underlined ...
.border-width-1 ...
.border-solid ...
</style>
...
<a href="#more" class="
  border-color-blue 
  text-color-blue 
  text-underlined 
  bg-color-white 
  border-width-1 
  border-solid
">...more</a>

But the code above is most flexible for all things. Perhaps this may be a solution for core styles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants