Modern Styling Rules: Let Containers Determine Position

This may seem obvious to some, and honestly isn’t even that “modern”, but it’s a good rule of thumb: Let containers determine position, not the individual component itself (usually).

I’m currently working on the core style system for components for the Ghost Gamer News website rebrand, and planning a relatively complex structure is just as important as actually writing code.


I’m trying to reduce the amount of “override” I have to write for my core components.

Let’s take a headline for example.

In the mock-up used as the feature image for this post, the very second headline (a sub-heading) is center-aligned. For posts and pages, that is the default state for that h2.

For in-post H2s, however, those headings are going to be left-aligned.

Now, I could certainly set the H2 to be text-align: center, and then use something like .articleContentWrap h2 { text-align: left; }, but that’s an unnecessary override.

Instead, let’s just set a .headingWrapper class to have text-align: center, which will also eliminate the need to center the h1, too.

While this is a fairly simplistic example, we can see additional benefit when it comes to repeated objects, utilizing things like grid and flex to control flow. If we have an outlier object we need to perform a special adjustment on positioning, we can either wrap it in a positioning container, or utilize a child-of selection method (such as .parent > .outlierObject).

This isn’t a 100% foolproof method, but it does help in a number of situations where you’ve got complete control of the codebase from initial development. It’s easier to understand, reduces the number of lines of CSS (or CSS-in-JS or whatever new flavor of the month comes well after this article is published), and still provides you options for overrides without getting too crazy with adding detail to the selectors to avoid inheritance issues (or, *shudder*, !important flags).

If you’re just getting started with front-end development, this may help. It’s an obvious thing to many developers, but not everybody thinks the same way.. Especially if you had some sketchy education early on.

Of course, when I’m in a rush, I’m guilty of skipping this.. Especially if I didn’t spend enough time on the initial planning phase of development. It’s not a huge deal, but it can simplify future maintenance and codebase extension later on.