-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Use inline styles instead of CSS variables for the style attribute #21428
Conversation
const mappings = { | ||
lineHeight: [ 'typography', 'lineHeight' ], | ||
backgroundColor: [ 'color', 'background' ], | ||
color: [ 'color', 'text' ], | ||
}; |
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.
This is the important part (mapping style objects to inline styles) each time we add a new config/CSS variable, we should the right mapping here.
Size Change: -258 B (0%) Total Size: 889 kB
ℹ️ View Unchanged
|
5c09c8c
to
6d21c0b
Compare
@nosolosw Good catch, it should be fixed. |
The following bit in .wp-gs .wp-block-button__link:not(.has-background) {
background-color: var(--wp--color--primary);
} I meant to delete it in some PRs that didn't land yet because it uses the |
We also need to bring back these editor-styles. |
@nosolosw I'm still curious to understand why. Maybe some specificity issue somewhere. |
I believe I ran into what you mention myself. However, I think it was due to the environment and not the plugin, though? I mention it because I'm not using any env bundled with Gutenberg for this testing. Also: yes, same palette. In case it rings any bell: |
OK, I think I got it. One thing that this PR modifies from WP 5.4 is that it doesn't inline the styles in the editor for presets (only for custom styles). It looks like that isn't enough for 2019 and this declaration kicks-in and takes precedence over the classes added by the presets. Perhaps we can add that behavior back, even for the presets? |
I'm pretty sure we didn't change anything about how presets are applied though. with or without this PR. |
I've come to this today with fresh eyes, and this is what I've observed: what I reported before happens for old and new content using the TwentyNineteen theme --- in this branch, but also in master. I've pinpointed this issue to the addition of color hooks to the paragraph block (before that it works nicely). This PR is a great addition that is good to land as soon as we can to avoid potential conflicts (like what happened for patterns). So, I wonder how do you want to proceed: shall we merge this one and investigate the issue separately? I'm happy to approve if so. |
Yes, let's do that, I'm planning to investigate the other issue today too. |
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've adapted #21431 to work with this.
I think I know what's happening. Previously we used to add the colors chosen as inline styles in the editor markup even if you choose a preset, while with the new approach, we're getting closer to the frontend and if you choose a palette color, we just apply the className. Twenty nineteen is not loading the entire palette color stylesheet in the editor which means when it's just the class that is added, the colors are not applied properly. I believe the new approach is the right one since it matches frontend and backend more closely but it means 2019 needs to be patched to load the palette colors on the editor too. |
Ok cool, that's doable. Are other themes having this problem too? |
Can't tell for sure, I can say that it works well in 2020 |
Just noting that I opened a core issue for this... https://core.trac.wordpress.org/ticket/50120 ... and also discovered that it requires patches for almost all of the core themes. This makes me a little nervous that this change might end up resulting in widespread breakage of the color palettes in the editor. The fact that 2020 includes its custom colors in the editor styles might just be an anomaly. |
@kjellr yeah, we should probably just add these inline styles again but I'm wondering how we can nudge folks to actually enqueue these styles in the editor too. |
For a lot of these sorts of updates, I see block-based themes & global styles as a potential changeover point. If your theme has block templates and a |
CSS attribues are nice for properties that are used in several blocks but they create a cascade issue for things like backgrounds, colors. When I set a background color on a group, I don't want its inner buttons to inherit it.