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

Chore: style Gutenberg file block #773

Merged
merged 17 commits into from
Jun 18, 2020
Merged

Conversation

derekshirk
Copy link
Contributor

@derekshirk derekshirk commented Jun 3, 2020

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"

Screen Shot 2020-06-03 at 4 10 40 PM

Styled WordPress output

file-hover

Example of Storybook documentation

Screen Shot 2020-06-03 at 4 37 41 PM

Testing

  1. View deploy preview
  2. Confirm links in story description are linked correctly
  3. Review CSS
  4. Confirm active, focus and Hover are working as expected

Issue

See #710

@derekshirk derekshirk self-assigned this Jun 3, 2020
@changeset-bot
Copy link

changeset-bot bot commented Jun 3, 2020

🦋 Changeset is good to go

Latest 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 derekshirk marked this pull request as ready for review June 3, 2020 23:42
@derekshirk derekshirk requested a review from a team June 3, 2020 23:42
@calebeby
Copy link
Member

calebeby commented Jun 3, 2020

@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.

npx changeset

If you have any questions, let me know!

@derekshirk
Copy link
Contributor Author

@cloudfour/dev This is still in need of review.

Copy link
Member

@spaceninja spaceninja left a 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 Show resolved Hide resolved
Comment on lines 99 to 104
&.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 */
}
Copy link
Member

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.

Copy link
Contributor Author

@derekshirk derekshirk Jun 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spaceninja,

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.

Copy link
Contributor Author

@derekshirk derekshirk Jun 5, 2020

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.

Copy link
Member

@spaceninja spaceninja Jun 5, 2020

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @spaceninja

src/vendor/wordpress/_wordpress.scss Outdated Show resolved Hide resolved
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).
Copy link
Member

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.

Copy link
Member

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.

*/

.wp-block-file__button,
:not(.wp-block-file__button) {
Copy link
Member

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?

@derekshirk
Copy link
Contributor Author

Currently blocked by #798

@derekshirk derekshirk added the ✋ blocked Can't proceed quite yet label Jun 16, 2020
@derekshirk derekshirk removed the ✋ blocked Can't proceed quite yet label Jun 16, 2020
@derekshirk derekshirk requested review from spaceninja and a team June 16, 2020 23:48
@derekshirk
Copy link
Contributor Author

Now that #798 is merged, this PR is ready for re-review.

Comment on lines +76 to +77
.wp-block-file__button,
* {
Copy link
Member

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.
 */

Copy link
Member

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?

Copy link
Contributor Author

@derekshirk derekshirk Jun 17, 2020

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 */
  }

  ...

@derekshirk derekshirk requested a review from spaceninja June 17, 2020 23:41
@derekshirk derekshirk requested a review from tylersticka June 18, 2020 16:12
@derekshirk
Copy link
Contributor Author

@tylersticka At your leisure, would you like to review this before I merge?

@tylersticka
Copy link
Member

@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.

@derekshirk derekshirk merged commit 62b6525 into v-next Jun 18, 2020
@derekshirk derekshirk deleted the chore/gutenberg-core-file branch June 18, 2020 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants