-
Notifications
You must be signed in to change notification settings - Fork 10.7k
[MVP QA #1] Visual: spacings #38325
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
[MVP QA #1] Visual: spacings #38325
Conversation
|
Hi @joshuatf, Apart from reviewing the code changes, please make sure to review the testing instructions as well. You can follow this guide to find out what good testing instructions should look like: |
Test Results SummaryCommit SHA: ab0329f
To view the full API test report, click here. To view the full E2E test report, click here. To view all test reports, visit the WooCommerce Test Reports Dashboard. |
fa4d6f0 to
d65b303
Compare
afa3a79 to
0bb738d
Compare
joshuatf
left a comment
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.
Looking great on my end! Thanks for the additional clean-up with notices in this PR.
Just left one question we discussed before. Let's see what @jarekmorawski says and we can update our naming accordingly.
| } | ||
|
|
||
| &__content { | ||
| &--block-gap-lg > * + * { |
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.
Nice! 🎉
| }, | ||
| "blockGap": { | ||
| "type": "string", | ||
| "enum": [ "lg", "2xlg" ], |
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.
We discussed this in our grooming call, but this is the only area the feels a little weird with the naming.
It would be great if we could match the gaps to our existing variable gap sizes (24px, 36px, 40px) and then match the naming there as well. @jarekmorawski is that feasible or do these gaps need to be different than our current gaps?
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.
Meaning that we'd change all the gaps between fields and sections to those you listed? I'd prefer to avoid that. The ones in Figma are consistent with WordPress (more or less) and balance white space and density well. For example, increasing the gap between sections from 32 px to 36 px or 40 px will impact how much content is visible before scrolling.
By the way, where do our current gap sizes come from and can we adjust them to the new ones?
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.
Those gaps came from the previous designers, but I'm unsure on the specifics of how they were chosen.
It would be really great to adjust them, though that would require changes in many places (a quick scan shows that we're using some form of the $gap variable in 762 files).
But if this is something we plan on doing one day, we could at least update the naming in this PR to match those. @jarekmorawski do you have ideal sizes for gaps/spacing for smallest, smaller, small, default, large, larger, and largest?
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.
If we update the gaps, it'll affect all of wc-admin, correct? We'd have to do an audit to make sure we wouldn't break the visual rhythm outside the form, so I can't specify them yet. For the form, let's use the sizes below.
I'll leave it to your judgment and BEM best practices regarding naming.
- XXS: 8px
- XS: 16px
- S: 24px
- M: 32px
- L: 40px
- XL: 48px
- XXL: 56px
We'll unlikely ever use gaps larger than 56 px for form elements or cards like in the Home screen. The only things I can think of are margins and paddings, but I'm not sure we should include them in the system.
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.
If we update the gaps, it'll affect all of wc-admin, correct?
Correct, but we're not looking at tackling that in this PR. Mostly just curious if it's something we'll eventually make sizes consistent between these and the existing gaps. If so, we can match the naming and eventually replace them.
On the other hand, providing new sizes (xxs, xs, s, etc) provides us an easier way to transition over. I'm indifferent between those sizes and using the previous semantics (smallest, smaller, small, etc). @mdperez86 do you have an opinion on this?
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.
@joshuatf in popular UI frameworks out there using (xs, sm, md, lg, xl) have become in a standard not only referring to a screen size but also to text-size and sometimes to spacing. But the problem this convention has is that the values are always fixed and we'll face the same problem in future if a new value appeared like now. Because of that some frameworks adopted a more scalable solution like using gap-1, gap-2, gap-3 -> 0.25rem /* 4px */, 0.5rem /* 8px */, 0.75rem /* 12px */ which give us infinite flexibility if a new value is required like 0.375rem /* 6px */ that can be represented as gap-1.5. Of course the downside of this approach is that is more difficult to recognize than a more descriptive names like xs or lg.
So I'm ok using the convention suggested by @jarekmorawski but just consider we could face the same problem we have now in the future.
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.
@mdperez86 I like that style better as well and I think WooCommerce is the only one tied to a system using our current style of naming. I think that bodes well for us switching to a new relative gap system.
Looks like WordPress has adopted a similar approach.. And luckily we already have access to those variables here:
Let's follow that convention and we can slowly deprecate our previous gap system in time.
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.
done -> ab0329f
…x and remove the line separating the header from the contents
…vertically misaligned. Left margin of 4 px, no vertical adjustment; somehow it has a -2px set for the top margin)
…d say Add, not Save. It should change into Update once it's published on the store
joshuatf
left a comment
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 all the hard work on this, Maikel! This is a big improvement on our current spacing and how we organize things.
I noticed some oddities around spacing and background color in my environment, but I think this is unrelated to this PR and has to do with Gutenberg styles bleeding through since I have the latest GB enabled. We can address that in a follow-up so we don't block this issue further.

| { | ||
| className: classNames( | ||
| 'wp-block-woocommerce-product-section__content', | ||
| `wp-block-woocommerce-product-section__content--block-gap-${ blockGap }` |
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.
Nice 👍
| const noticeContent = isCreating | ||
| ? __( 'Product successfully created.', 'woocommerce' ) | ||
| : __( 'Product published.', 'woocommerce' ); | ||
| const noticeContent = isPublished |
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.
Noted this in the other PR, but won't let it block this PR since it's fixed there.
| } | ||
| } | ||
|
|
||
| .components-modal__content { |
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.
Hi, @mdperez86! It looks like .components-modal__content is way too general, it's affecting all modals in admin.
Originally reported by Vlad Olaru in this slack p1686918124623299/1686328973.559239-slack-C01SFMVEYAK.
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.
Hi @ilyasfoo, thank you for reporting that.
I created this issue and I'm working on a fix now.

Submission Review Guidelines:
Changes proposed in this Pull Request:
Closes #38202
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
/wp-admin/tools.php?page=woocommerce-admin-test-helperproduct-block-editor/wp-admin/admin.php?page=wc-admin&path=/add-product