-
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
Buttons: Update selectors to work better with button elements #43022
Conversation
I also believe that the style variations should take precedence -The theme developer can de-register the style variations if they do not want them, and also register their own. |
Size Change: -7 B (0%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
Hey, I just saw #41934 and suggested reverting there. Given how big a change it is, can we consider a PR just reverting that change and a different one to explore alternatives solutions to the button block? That way we can fast-track the revert while the conversations about the button's issues continue. |
Oh, I've just realized that this doesn't revert completely #41934 There are changes to the file, post comments, and search blocks (plus other theme.json changes) that are not being reverted. Shall we? I haven't been able to completely follow the conversation but wanted to raise for awareness. |
I think all the button block issues are resolved (except the one that this fixes) which is why I don't really want to revert that part of the change in #41934. Are there other issues I am missing? |
Maybe this shouldn't be a draft anymore? I think this reverts the problematic part of #41934 while fixing both underlying issues |
The padding issue from #34853 is still valid, correct? |
I think that is working as intended. Right now the only way we have to control style variations is CSS, so they are meant to override theme.json settings for the base block (otherwise the outline style would look basically the same as the base button). I wish that would change in the future so instead of using CSS, variations can be defined and edited using theme.json/block.json instead. |
What?
This is another attempt to fix #42097, which is significantly simpler than #42991.
Why?
The aim is to ensure that button outline style appear the same in the frontend and the editor.
How?
In #41934 we made some changes to the way that block styles were loaded, so that they are dependent on global styles, and therefore load later. The is problematic, as it doesn't match the order that styles load in the post and site editor, and that is hard to change (see #42991).
The proposal here is to revert that change, and instead handle the discrepancy using CSS specificity.
This change adds a
.wp-block-button
class to the selector for block buttons, so that it will be stronger than the.wp-element-button
selector. It makes a similar change to the outline button styles to ensure that they are stronger than the theme.json settings.Testing Instructions
Here's some sample markup:
Scenario 1: Button element rules in theme.json
Scenario 2: Button block rules in theme.json
Scenario 3: Button element and block rules in theme.json
In all three scenarios check both normal buttons and outline buttons. Also check that things look the same in the frontend, the site editor and the post editor.
Questions
There is an open question here about how block style variations should interact with theme.json settings - should the block styles take precedence, or the setting from theme.json? Either way we still need to make changes here to ensure the behaviour is the same in the editor and the frontend. In #35438 the intention seems to be that block style variations are overridden by theme.json, but the problem I see with that is that, for example, outline buttons for example will start to look the same as regular buttons. My view is that the style variation should take precedence, which is what I have done in this PR, but I'm open to rethink that. cc @oandregal @mtias