Missing margin when using cart and checkout blocks in full width mode

[nielslange]

Describe the bug

• When using the cart block in full width mode, the block touches the left border of the browser.
• When using the checkout block in full width mode, the block touches the left and the right border of the browser.

To reproduce

Steps to reproduce the behavior:

1. Create a test page and add the cart block.
2. Set the block to full width and save the test page.
3. Look up the cart block in the frontend and see that there's no spacing on the left-hand side.
4. Create another test page and add the checkout block.
5. Set the block to full width and save the test page.
6. Look up the checkout block in the frontend and see that there's no spacing on the left-hand and the right-hand side.

Expected behavior

I expected that both the cart and the checkout block have some spacing between the block and the browser border.

Screenshots

Cart:

Checkout:

[senadir]

Is this a storefront issue or is this behavior consistent in all themes? Should Cart/Checkout provide margin when they're full width anyway? isn't this a responsibility for the parent block (group, template part...)

[nerrad]

I agree with Nadir here, I wonder if this more a theme issue.

[nielslange]

Is this a storefront issue or is this behavior consistent in all themes?

It's consistent in all themes. At least, I checked the following default themes and they all show the same behaviour:

• Twenty Twenty-One
• Twenty Twenty
• Twenty Nineteen

Should Cart/Checkout provide margin when they're full width anyway?

I cannot answer that question, but I can say that our current approach is inconsistent, as the cart block shows a right-margin in full-mode. In my opinion, both the cart and the checkout blocks should either have a default margin on both sides or no margin at all.

isn't this a responsibility for the parent block (group, template part...)

Relying on a parent block, could solve the problem. That said, it would also require adding an extra element to the DOM. Thus, instead of adding the cart or checkout block directly, a merchant would have to add a group block first and then add the cart or checkout block as the only element to it.

[nielslange]

@senadir & @nerrad Do you think it's worth moving this issue back to the Tier One Backlog or shall better move it to the Icebox?

[nerrad]

@niels, I'm not seeing quite the same thing as you in my testing (using Chrome browser).

Cart	Checkout

I'm seeing equal margin on both sides. The cart does have less margin than the checkout though.

What might be beneficial here is to see if this is a change from the previous iteration of the blocks.

[nielslange]

I have no explanation why you're seeing a different result, @nerrad. I see the same result, that I posted in the description, both in Local by Flywheel and in https://jurassic.ninja/ and https://tastewp.com/.

The only recent change I could find is the following change, that added margin to the cart order summary block:

https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/76d565b83fba4e6d3ce658275206eeb94cd15510/assets/js/blocks/cart-checkout/cart/style.scss#L241-L246

[nerrad]

I have no explanation why you're seeing a different result, @nerrad.

Let's figure this out then.

• I'm testing on latest Chrome browser (stable branch)
• I was using the latest npm run build version of WooCommerce blocks testing locally (in case the latest trunk is already fixed).
• Storefront 3.5.1 (it's a development version I think).
• WooCommerce 5.8.0-dev (development version of WooCommerce)
• Gutenberg is not active (but even with it active I'm not seeing the same margin problem).

That's just a short list of things that might impact different behaviour. If we're still not able to determine the cause from comparing environments, the next step might be to get another team member to try and verify, but I can just add this for the next person doing porter rotation to look at.

Also related to this comment:

Relying on a parent block, could solve the problem. That said, it would also require adding an extra element to the DOM. Thus, instead of adding the cart or checkout block directly, a merchant would have to add a group block first and then add the cart or checkout block as the only element to it.

I think Nadir wasn't necessarily saying that a group block would have to be added. He's just referring to how margins for alignments should be primarily controlled by the wrapping container, whether that comes from a block (group or column), a template part, a template, or a theme.

[nielslange]

@nerrad I created a fresh site using Local by Flywheel and I still do not see the margins on my end. These are the versions I'm running:

• WordPress 5.8.1
• WooCommerce 5.8.0 (via WordPress.org plugin directory)
• WooCommerce Blocks 6.3.0-dev (via local GitHub repo)
• Storefront 3.9.1 (via local GitHub repo)
• Chrome 95.0.4638.69

WooCommerce system status report

### WordPress Environment ###

WordPress address (URL): http://woo.local
Site address (URL): http://woo.local
WC Version: 5.8.0
REST API Version: ✔ 5.8.0
WC Blocks Version: ✔ 6.3.0-dev
Action Scheduler Version: ✔ 3.3.0
WC Admin Version: ✔ 2.7.2
Log Directory Writable: ✔
WP Version: 5.8.1
WP Multisite: –
WP Memory Limit: 256 MB
WP Debug Mode: ✔
WP Cron: ✔
Language: en_US
External object cache: –

### Server Environment ###

Server Info: nginx/1.16.0
PHP Version: 7.3.5
PHP Post Max Size: 1,000 MB
PHP Time Limit: 1200
PHP Max Input Vars: 4000
cURL Version: 7.54.0
LibreSSL/2.6.5

SUHOSIN Installed: –
MySQL Version: 8.0.16
Max Upload Size: 300 MB
Default Timezone is UTC: ✔
fsockopen/cURL: ✔
SoapClient: ✔
DOMDocument: ✔
GZip: ✔
Multibyte String: ✔
Remote Post: ✔
Remote Get: ❌ wp_remote_get() failed. Contact your hosting provider.

### Database ###

WC Database Version: 5.8.0
WC Database Prefix: wp_
Total Database Size: 4.92MB
Database Data Size: 3.47MB
Database Index Size: 1.45MB
wp_woocommerce_sessions: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_api_keys: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_attribute_taxonomies: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_downloadable_product_permissions: Data: 0.02MB + Index: 0.06MB + Engine InnoDB
wp_woocommerce_order_items: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_order_itemmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_tax_rates: Data: 0.02MB + Index: 0.06MB + Engine InnoDB
wp_woocommerce_tax_rate_locations: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_shipping_zones: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_woocommerce_shipping_zone_locations: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_shipping_zone_methods: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_woocommerce_payment_tokens: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_payment_tokenmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_log: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_actionscheduler_actions: Data: 0.02MB + Index: 0.13MB + Engine InnoDB
wp_actionscheduler_claims: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_actionscheduler_groups: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_actionscheduler_logs: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_commentmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_comments: Data: 0.02MB + Index: 0.08MB + Engine InnoDB
wp_links: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_options: Data: 2.48MB + Index: 0.06MB + Engine InnoDB
wp_postmeta: Data: 0.13MB + Index: 0.06MB + Engine InnoDB
wp_posts: Data: 0.06MB + Index: 0.06MB + Engine InnoDB
wp_term_relationships: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_term_taxonomy: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_termmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_terms: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_usermeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_users: Data: 0.02MB + Index: 0.05MB + Engine InnoDB
wp_wc_admin_note_actions: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_wc_admin_notes: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_wc_category_lookup: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_wc_customer_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_download_log: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_order_coupon_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_order_product_lookup: Data: 0.02MB + Index: 0.06MB + Engine InnoDB
wp_wc_order_stats: Data: 0.02MB + Index: 0.05MB + Engine InnoDB
wp_wc_order_tax_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_product_meta_lookup: Data: 0.02MB + Index: 0.09MB + Engine InnoDB
wp_wc_reserved_stock: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_wc_tax_rate_classes: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_wc_webhooks: Data: 0.02MB + Index: 0.02MB + Engine InnoDB

### Post Type Counts ###

attachment: 24
nav_menu_item: 8
page: 8
post: 1
product: 19
product_variation: 7
revision: 6
shop_order: 1

### Security ###

Secure connection (HTTPS): ❌
					Your store is not using HTTPS. Learn more about HTTPS and SSL Certificates.
Hide errors from visitors: ❌Error messages should not be shown to visitors.

### Active Plugins (2) ###

WooCommerce Blocks: by Automattic – 6.3.0-dev
WooCommerce: by Automattic – 5.8.0

### Inactive Plugins (0) ###


### Settings ###

API Enabled: –
Force SSL: –
Currency: USD ($)
Currency Position: left
Thousand Separator: ,
Decimal Separator: .
Number of Decimals: 2
Taxonomies: Product Types: external (external)
grouped (grouped)
simple (simple)
variable (variable)

Taxonomies: Product Visibility: exclude-from-catalog (exclude-from-catalog)
exclude-from-search (exclude-from-search)
featured (featured)
outofstock (outofstock)
rated-1 (rated-1)
rated-2 (rated-2)
rated-3 (rated-3)
rated-4 (rated-4)
rated-5 (rated-5)

Connected to WooCommerce.com: –

### WC Pages ###

Shop base: #78 - /shop/
Cart: #66 - /cart/
Checkout: #68 - /checkout/
My account: #12 - /my-account/
Terms and conditions: ❌ Page not set

### Theme ###

Name: Storefront
Version: 3.9.1
Author URL: https://woocommerce.com/
Child Theme: ❌ – If you are modifying WooCommerce on a parent theme that you did not build personally we recommend using a child theme. See: How to create a child theme
WooCommerce Support: ✔

### Templates ###

Overrides: –

### Action Scheduler ###

Complete: 28
Oldest: 2021-11-03 07:55:07 +0000
Newest: 2021-11-03 07:58:39 +0000

Pending: 2
Oldest: 2021-11-04 07:50:03 +0000
Newest: 2021-11-04 07:54:47 +0000


### Status report information ###

Generated at: 2021-11-03 08:04:40 +00:00

I did not install Gutenberg this time and I noticed that you're using Storefront 3.5.1, while I'm using Storefront 3.9.1. When trying to build Storefront 3.5.1, I received the following error in the console:

npm run build                                                                                             ✔  12.21.0  

> [email protected] build /Users/nielslange/Themes/storefront
> grunt deploy --env=production

Running "stylelint:all" (stylelint) task
>> Deprecation Warning: 'declaration-property-unit-whitelist' has been deprecated. Instead use 'declaration-property-unit-allowed-list'. See: https://github.com/stylelint/stylelint/blob/13.7.0/lib/rules/declaration-property-unit-whitelist/README.md
>> Linted 32 files without errors

Running "sass:dist" (sass) task
Fatal error: Error: It's not clear which file to import for '@import "buttons"'.
       Candidates:
         buttons.scss
         buttons.css
       Please delete or rename all but one of these files.
        on line 1 of assets/css/admin/admin.scss
>> @import "buttons";

   ^

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `grunt deploy --env=production`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/nielslange/.npm/_logs/2021-11-03T08_16_26_460Z-debug.log

If we're still not able to determine the cause from comparing environments, the next step might be to get another team member to try and verify, but I can just add this for the next person doing porter rotation to look at.

@frontdevde As you're porter this week, would you mind checking if you're able to reproduce this problem?

[frontdevde]

@frontdevde As you're porter this week, would you mind checking if you're able to reproduce this problem?

I'm currently prioritizing the work remaining on the Store Editing Templates v1 project to ensure we can ship it this week. I'll put it on my to-do list for the end of the week but I can't promise I get to it (depending on how things go on the project).

[Aljullu]

I can reproduce the same as @nielslange.

I think there are a couple of issues here:

1. Sidebar is inconsistent between Cart (has marging) and Checkout (has no margin). This happens no matter if the blocks are set to full width or have no alignment: you can notice it when switching from Cart to Checkout when following the purchase flow. To make it easier to notice, in this image, you can see both sidebars:

2. Having no margin when the blocks are set to Full width. I think that's to be expected, the same happens if you add a Cover block or a Gallery block and make them Full width. However, it's true that is look quite bad for C&C blocks. So I think we could evaluate two solutions (or work-arounds):

• Add a Margin global style so users can make them full width but add margin around them.
• Simply remove the Full width alignment. There is already Wide width alignment which seems to work better because it's wider than the main content but it doesn't collide with the screen edges.

[nielslange]

So I think we could evaluate two solutions (or work-arounds):

• Add a Margin global style so users can make them full width but add margin around them.
• Simply remove the Full width alignment. There is already Wide width alignment which seems to work better because it's wider than the main content but it doesn't collide with the screen edges.

I just checked the wide alignment, and it works perfect. Independent of the screen width, there's always an outer margin visible. I'll go with this solution for now. We can always iterate towards a full-width solution later, if really needed.