@mejiaj Going off of your comment, it looks like there are margins being set by .grid-row.grid-gap>* that is causing that space on the right.

Should we consider this a breaking change because we're editing markdown?

Yes, it'd be a breaking change because of markup. I've added the Needs: discussion tag to the original issue, so we can discuss before making the change.

Happy to tackle simplifying the HTML/CSS upon your discussion. Let me know if we'd like to remove the grid utilities on just the sections @mejiaj mentioned, or the whole component. (Or any other requirements that emerge.)

@danbrady after discussing with the team let's move forward with removing grid classes from component ― starting with the problematic areas.

@mejiaj To confirm, the goal for the next step is to remove all grid classes from problem areas (footer logo, social logos, and addresses) and get equivalent layout using flex utilities, but leave the grid classes (and usa-layout-grid package) in for the rest of the footer(s)?

@danbrady sorry I missed this message.

Yes, we're keeping grid classes (to prevent breaking change), but removing the grid layout dependency in SASS.

No problem, @mejiaj! That's the direction I took. I have a WIP PR (#5289) for removing the grid dependency but need some guidance, when you have the chance. I'll tag you for review. Thanks!

This updates the markup to remove the errant space defined in the issue. I've updated the markup, but only to use existing classes so I don't believe it's a breaking change? Thanks!

Hey there @danbrady!

Any changes to component markup are considered breaking changes because they require users to manually update the markup in their component code.

It'd probably be a better idea to return to a scss based solution for this one.

Hi @mahoneycm / @mejiaj! Sure, I'll take a look and see if we can fix it with SCSS alone and not change any markup. We'll probably have to override grid/flex classes for this case.

So I understand for next time, can you explain to me why this instance would be a breaking change? I understand that if a user updates markup and it refers to updated CSS that hasn't been published it would actually break a component. However, while this change does change the markup, it only changes markup that refers to existing/unchanged styles. If it doesn't reference any new or changed classes, the change should operate ok whether the user updates the markup or not, no?

(BTW, I'm not disagreeing. Just want to learn :)

Note: PR updated!

@danbrady historically these types of changes bring difficulties to users, especially those on small teams trying to stay up-to-date with USWDS.

We're working on improving how we communicate breaking changes & how we can make upgrading easier. In the meantime, we're trying to avoid changing markup.