-
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
Remove core/post-comments-form block styles that are overriding button element styles #42053
Conversation
…hey are overriding the core/block button styles.
Size Change: +6.79 kB (+1%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
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 think we should only remove the styles that are provided by core theme.json
. For example cursor:pointer
is not, so it should remain. Testing this I saw no difference because the class .wp-block-button__link
in the button block's CSS adds cursor:pointer
, but IMO it should not be removed - same to all other CSS that are not in theme.json
.
e86b893
to
c5429d9
Compare
I updated the testing instructions following the issue conversation. |
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.
Let's land this 👍🏻
I am not fond of the browser default border that will be used if theme authors do not style this button, but I also do not have a solution for it. |
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.
Let's wait on figuring out what's up with the roundness in @carolinan 's tests
…e.scss file to make them available on the frontend.
…o avoid unwanted styles
The problems around border-radius found by @carolinan preexist this PR and they are not strictly related to the original intention of this PR. Apart from that, I added a default setting in Gutenberg's default In this screenshot, you can see that both problems seem to be solved. For this example, I'm using
With Gutenberg plugin disabled still are some visual discrepancies between the editor and the frontend caused by some admin CSS definitions. I may have a fix for that, I'm testing it. Due it is a core-problem that needs to be fixed in core repo I think we can move forward with this PR. Thanks @carolinan and @draganescu for your feedback! |
I think that class pre-dates that PR... |
@@ -34,7 +34,6 @@ const CommentsForm = () => { | |||
name="submit" | |||
type="submit" | |||
className={ classnames( | |||
'submit', |
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.
Where else is this class? If it's not needed should we remove the directives as well?
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 haven't found the class anywhere else in Gutenberg codebase.
The CSS directives live in the WordPress core repo: https://github.com/WordPress/wordpress-develop/blob/0a17a80bccd452b91c3b63f71f010ba131a2c954/src/wp-admin/css/forms.css#L415-L421
The new updates seem to solve the problems
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 looks good to me 👍
I have originally added the submit
classes in 08d34f3 when creating the Post Comments Form for the editor. The only reason for adding it was because the PHP (non-block) comments also include it.
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.
Uh, I'm sorry for having to revoke my approval 😅
I have noticed that the submit
class is also applied on the frontend through the comment_form_defaults
filter:
add_filter( 'comment_form_defaults', 'post_comments_form_block_form_defaults' ); |
This is where the comment_form_defaults
filter is being applied in Core.
This filter was introduced to the Post Comments Form block in #40628 because of the feedback in #34994 (comment).
So, I think we should either remove the submit
class in both places or keep it in both 🙂 .
Thanks for your detailed feedback @michalczaplinski ! |
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 think that's fine! 🙂
There is only one class (submit
) applied to the button which is defined here and added to the final markup here
Also, I wanna note this comment which confirms that CSS classes can change from time to time given good reasons (I'm paraphrasing).
What?
Remove core/post-comments-form block styles that are overriding button element styles from
theme.json
Why?
These styles are preventing that the
theme.json
styles for button elements apply over the core/post-comments-form submit button.How?
I think those styles can be removed because they are no longer needed and they are conflicting with the button element styles.
Testing Instructions
Screenshots or screencast
Using the
theme.json
from the top ⬆️ example:Before:
After: