-
Notifications
You must be signed in to change notification settings - Fork 3
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
Chore: style Gutenberg file block #773
Conversation
🦋 Changeset is good to goLatest commit: 24e0515 We got this. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@derekshirk Can you add a changeset for this PR? I think this should go as a minor release since it adds functionality in a non-breaking way. We are releasing every PR with outwards-facing changes as its own release.
If you have any questions, let me know! |
@cloudfour/dev This is still in need of review. |
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.
Left some nitpicky code formatting questions, but overall I have no objections.
src/vendor/wordpress/_wordpress.scss
Outdated
&.c-button--tertiary .wp-block-file__button, | ||
&.c-button--tertiary :not(.wp-block-file_button) { | ||
@include button.tertiary; | ||
color: inherit !important; /* 1 */ | ||
opacity: inherit !important; /* 1 */ | ||
} |
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.
Would it make sense to merge this with the previous block for c-button--secondary
? That might avoid some duplication.
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.
Would it make sense to merge this
When you mention "this", are you referring to the color
and opacity
values, or the entire block? 🤔
This is how I interpreted your suggestion to consider "merging with the previous block.
&.c-button--secondary .wp-block-file__button,
&.c-button--secondary :not(.wp-block-file__button) {
@include button.secondary;
}
&.c-button--tertiary .wp-block-file__button,
&.c-button--tertiary :not(.wp-block-file_button) {
@include button.tertiary;
}
/**
* 1. Prevents default WP styling from modifying buttons opacity and
* text color.
*/
&.c-button--secondary .wp-block-file__button,
&.c-button--secondary :not(.wp-block-file__button),
&.c-button--tertiary .wp-block-file__button,
&.c-button--tertiary :not(.wp-block-file_button) {
color: inherit !important; /* 1 */
opacity: inherit !important; /* 1 */
}
However, I don't have a high level of confidence that this is what you intended.
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.
You can ignore my comment above, if you'd like. 😉
Excuse my additional, "think-out-loud" comments on this thread...
I've ended up with this:
(These comments do not exist in source)
.wp-block-file {
...
/**
* If I don't include `:not(.wp-block-file__button)` here and opt for `*` instead,
* this selector is not specific enough to enforce the desired styles, as rules from the
* `@wordpress/block-library` override various properties.
*/
.wp-block-file__button,
:not(.wp-block-file__button) {
@include button.default;
opacity: inherit !important;
}
/**
* If I don't include `wp-block-file__button` here, this selector is not
* specific enough to enforce the desired styles, as rules from the
* `@wordpress/block-library` override various properties.
*
* 1. I tried _only_ using the `*` selector here but ran into the same specificity issue.
* 2. If I'm forced to use `:not(.wp-block-file__button)`, I considered using it here
* as well in hopes of perceived consistency
*/
&.c-button--secondary {
.wp-block-file__button,
* {
@include button.secondary;
color: inherit !important;
}
}
/**
* If I don't include `wp-block-file__button` here, this selector is not
* specific enough to enforce the desired styles, as rules from the
* `@wordpress/block-library` override various properties.
*
* 1. I tried _only_ using the `*` selector here but ran into the same specificity issue.
* 2. If I'm forced to use `:not(.wp-block-file__button)`, I considered using it here
* as well in hopes of perceived consistency
*/
&.c-button--tertiary {
.wp-block-file__button,
* {
@include button.tertiary;
color: inherit !important;
}
}
}
In response to the original concern of duplication, I was able to remove the opacity property from two selectors. Regarding the remaining color
property, it was not my findings that this produced unnecessary duplicative CSS output.
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.
That looks great! I'll be honest, in my original comment I intended you to combine the secondary and tertiary blocks, but that was because I missed that they were including different styles. My bad. Your changes combined with these comments look good.
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.
Thanks @spaceninja
This block creates a `div` with class `wp-block-file`, which wraps one or two | ||
`a` elements, the second of which (toggled in the editor) is meant to be styled | ||
as a button, adding the class `wp-block-file__button`. | ||
This block creates a parent `div` with a `wp-block-file` class name, which wraps a single `a` element. The Gutenberg editor allows file downloads to be displayed as buttons (`wp-block-file__button`) or text-only links. Our CSS styles both configurations as [buttons](/?path=/docs/components-button--elements). |
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.
House style question here (that might be for @tylersticka):
Do we prefer keeping Markdown paragraphs all on one line, or adding line breaks to avoid text extending past 80 characters?
Note that the text will render the same way, so this is strictly a code formatting question.
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.
Personally, I'm a fan of semantic line breaks to keep code readable.
src/vendor/wordpress/_wordpress.scss
Outdated
*/ | ||
|
||
.wp-block-file__button, | ||
:not(.wp-block-file__button) { |
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.
Could you change :not(.wp-block-file__button)
to *
and add the same comment explaining why here?
…atterns into chore/gutenberg-core-file
Currently blocked by #798 |
…atterns into chore/gutenberg-core-file
Now that #798 is merged, this PR is ready for re-review. |
.wp-block-file__button, | ||
* { |
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.
Can you add a comment somewhere explaining why you're targeting the class AND the universal selector? Earlier you had this comment, which was helpful to prevent someone else coming in later and thinking they can optimize your code by removing the class:
/*
* If I don't include `wp-block-file__button` here, this selector is not
* specific enough to enforce the desired styles, as rules from the
* `@wordpress/block-library` override various properties.
*/
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 don't think you need to repeat the comment in each selector — maybe add a footnote comment to each that references the earlier footnote?
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.
Thanks for your feedback @spaceninja.
maybe add a footnote comment to each that references the earlier footnote?
Forgive my ignorance here, but I wasn't actually sure how to implement a "footnote comment" or a numerical comment, in the same way we do on properties of a classname.
So...this is what I ended up with:
/**
* The following three selectors target a class name _and_ a universal
* selector (*). This is intentional because the Gutenberg file block can
* generate two different elements, a file-link and a file-button and we
* want to style both of them with the same visual appearance and
* characteristics. We could easily have chosen `:not(.wp-block-file__button)`
* but opted for less characters.
*
* 1. Prevents default WP styling from modifying buttons opacity on hover.
*/
.wp-block-file__button,
* {
@include button.default;
opacity: inherit !important; /* 1 */
}
...
@tylersticka At your leisure, would you like to review this before I merge? |
@derekshirk I gave it a quick pass and it seems to do what I'd expect it to! I trust you and @spaceninja to have looked more deeply. |
Overview
See #710
This PR introduces styles for Gutenberg file blocks. File blocks can be displayed in one of two ways, as a "download link" or as a "download button".
The changes being introduced here, style both links and buttons with primary, secondary and tertiary button styles.
Screenshots
Example of the WP Gutenberg (file) block editor interface, demonstrating "download links" and "download buttons"
Styled WordPress output
Example of Storybook documentation
Testing
Issue
See #710