Standard practice for managing responsive vertical spacing/padding

I’ve read some conflicting approaches on how to manage vertical spacing when designing responsively, and wanted to get clarity from the Finsweet team on what the accepted (internal) approach is to this issue.

Example: The design of our current build requires copious negative space above and below a section’s content area. We’re using padding-section-large and created our own padding-section-huge to achieve parity with the design. The desktop build works well with this approach using the built-in classes. Switching to tablet and mobile views, however, is problematic; it retains the same amount of space visually and doesn’t scale to smaller padding sizes gracefully.

This makes sense if the philosophy is to remain agnostic and allow the individual designer to decide how that spacing should appear on tablet and mobile devices, but I want to develop good practices early in the process so we do not have to fix non-standard implementations later on down the road.

The simplest solution appears to be, enable tablet view, override the spacing, and then move down to the next view.

How does Finsweet tackle this issue?

The same thing goes for the spacing blocks, which is the method we’ve adopted. Using a “spacer-large” below a header, for instance, looks great on desktop, but doesn’t work well for mobile. It feels wrong to simply override this ourselves – like we’re missing something.

This request probably seems rudimentary, but I could not find anyone that knew the official approach to this use case and thought it best to ask. I have an extremely particular approach to following standards, even after two decades of doing this work.

Thanks so much for the feedback!

Hey @BracketWrench!

Great question :wink:

You can override the spacing on breakpoints the way you need. It’s okay to have a padding-bottom padding-large 6rem on desktop, 3rem on tablet, and 2rem on mobile if you want.

In some cases where you need a different value for a specific breakpoint, you can also add a combo class like spacer-large is-mobile-smaller and use this combo class when is recurring.

Let me know if that helps. In case you want a more specific answer, please try sharing a screenshot of the structure and your read-only link.


1 Like

This makes good sense. I wasn’t sure if I was missing an obvious step, but catering the padding to device size on an individual project level sounds like the most flexible solution. I also like the combo class idea in specific cases where something more granular is required.

It felt a little strange to start adjusting the padding on the Finsweet classes (like section-padding-large) for different breakpoints, but if that’s the best approach that makes life much easier.

1 Like