1. 7

  2. 4

    This is good info, but applying it requires your team to be disciplined.

    As an extension to these ideas, I think it’s useful here to consider fully separating page layout components from content components.

    For instance, if you have a header/navbar/footer/two-column-content layout:

    • Write & test the code that drives the high-level layout
    • Write & test the code that generates the content for each visual component
    • Inject the content into the layout
    Why it’s good:

    This approach is robust in the face of changing designs, and makes it much clearer how to correctly use padding/margin (because you develop components in isolation).

    Why it’s hard:

    Tools support is spotty out-of-the-box (e.g. react does, rails doesn’t).

    You’ll often need to wire up some way to render each part of the app in isolation so you can test them as you go.

    1. 2

      The alternative take — yet equally rigorous — is to only apply margins in one direction. I can remember having my mind blown by a Harry Roberts article a few years ago on this very topic. He suggests using margin-bottom to push things down, and margin-left to push things across.

      Understanding margins and padding — along with a little * { box-sizing: border-box; } — is really what allowed me to wrap my mind around CSS.

      1. 1

        that’s really interesting, thanks! as someone just learning CSS it’s great to be able to draw on best practices other people have worked out the hard way.