It’s 2020 and while there are many things I do know, there are still some trivial silly things I do not or always forget. Case in point being, how to centre columns in a Bootstrap 4 layout.

Unlike Bootstrap 3, Bootstrap 4 uses Flexbox and therefore, you have more options for centring your layouts. One such method is the justify-content-center class defined on the row which will align the columns center. Finally, you use the text-center class to middle align the content of the column.

<div class="container">
    <div class="row justify-content-center">
        <div class="col-6 text-center">
            <p>My content</p>
        </div>
    </div>
</div>

This works by using the Flexbox property for justifying the content. We can also specify a column is display: flex; and align its contents like so as well, which can work well in certain situations.

<div class="container">
    <div class="row">
        <div class="col d-flex justify-content-center">
            <p>My content</p>
        </div>
    </div>
</div>

In the above, you might notice we don’t use text-center to center the text, we just make the column d-flex which makes it a flex element and its children and be aligned.

Nothing overly fancy. This post serves as more of a reminder to myself, but if you find it useful then that is a win as well.

Without-a-doubt layout in any modern website or application is one of the most challenging parts, especially when you want it to work on both desktop and small handheld devices like iPhone’s.

For a project I am working on, I have been extensively using Flexbox for the layout where applicable. One such layout is a grid of blog posts at the bottom of each page for clickthrough.

These items have varied length post titles and imagery. It only takes one title to be shorter than the others and float:left and display:inline-block solutions fall apart.

The kind of layout I am dealing with is a maximum of 4 items. When screen size permits, all 4 items are shown. As the screen size gets smaller, columns are dropped. 4, then 3, then 2 and finally 1.

One other constraint was the first and last items for smaller displays were to rest against the side of the container (with no space added). Only the middle items would have gutters.

The final solution I ended up coming up with was:

/* Wraps all blocks */
.blocks {
    display: flex;
    flex-wrap: wrap; /* Items drop below if they exceed width limitations */
}

.blocks__block {
    background: #FFF;
    display: flex;
    overflow: hidden;
    width: 100%;
}

    .blocks__block__inner {
        display: flex;
        flex: 1 0 auto; /* Grow inner content to make grid items all same size */
        flex-direction: column;
        margin: 0 0 15px 0;
        width: 100%;
    }

@media all and (min-width: 40em) {
    .blocks__block {
        width: 50%;
    }

    .blocks__block:nth-of-type(2) .blocks__block__inner,
    .blocks__block:nth-of-type(4) .blocks__block__inner {
        margin-left: 15px; 
    }
}

@media all and (min-width: 60em) {
    .blocks__block {
        width: 25%;
    }

    .blocks__block:first-child .blocks__block__inner { margin-left: 0; }
    .blocks__block:last-child .blocks__block__inner { margin-right: 0; }

    .blocks__block__inner {
        margin: 0 15px;
    }
}

I realise this isn’t the prettiest of code, but my needs more sort of specific so I could use nth-of-type to ensure the second and fourth items in my grid of 4 items were overridden when going to the two column layout.

Please feel free to use the above code in your projects, hopefully this helps you out as much as it helped me out. Also, remember to run the code through Autoprefixer or equivelent to get browser prefixes depending on browsers you support.

As great as CSS is, there are some glaring holes within the specification. We can perform calculations using the calc function in CSS, but for some reason there is no list-style-type: dash but other strange values like lower-greek and plenty of other language specific values.

The solution is quite simple and I decided to make this into a post for future reference and anyone else who finds themselves searching Google for the same thing.

ul.dashed {
    list-style: none;
    padding-left: 0;
}

ul.dashed > li {
    margin-left: 15px;  
}

/* Prevent nested li's from getting messed up */
ul.dashed > li::before {
    content: "-";
    margin-left: -15px;
}

You can replace the hyphen with anything you want, perhaps an emdash or endash? Maybe even an icon from an icon font. Go wild.

I love front-end development, but there is one thing about it that I do not particularly like: naming things. Using ID’s and classes on HTML elements and deciding what to name things in CSS is extremely hard. Even harder than solving cross-browser bugs.

Proving how difficult naming in CSS is, there are numerous methodologies such as; SMACSS (Scalable and Modular Architecture for CSS), BEM (Block Element Modifier), OOCSS (Object Oriented CSS), ACSS (Atomic CSS Architecture) and a few others.

Even though we have all of these methodologies at our disposal, they each have their own caveats and learning curve. They all also have the downside of locking you into their way of thinking and working. Once you commit to BEM, that’s it. You can’t choose to use another methodology.

Is there a better way?

To be quite honest, there isn’t. The nature of not only CSS, but programming in general is deciding what to name something is always going to be one of the hardest things you will face.

As Phil Karlton was famously quoted as saying:

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

This couldn’t ring anymore true. Do you give your header element an ID of header, do you give it a class of header or do you use a <header> element and style that in your CSS? We have so much choice and everyone seems to have an opinion on the best approach.

Which methodology?

I personally use a variation of the BEM methodology. But having said that, it can be annoying to use something like BEM because it requires you to do a lot of thinking when it comes to naming. Should a child element becomes its own block or should I make it a child element of a block?

Sometimes you end up with long CSS selectors when using BEM like: parent-element__child-element--modifier

This kind of selector is very verbose. It tells us what each element is called, we know we have a parent element, child element and a modifier class. But try and select that line using a double click in your IDE. You’ll notice your IDE will only partially select this line, unless you use the keyboard (which many don’t) then you’ll have to select it some other way.

Methodologies introduce complexity

So you have picked a methodology and now comes the hard part. Training yourself to stick to the rules of said methodology and not only that, if you are working on a team, ensuring everyone else is onboard and understands the constraints of said methodology.

In my experience, this is where things fall apart. While methodologies like BEM give us structure and some rules to abide by, it can take some time before everyone has conditioned themselves. CSS has been this wild west thing for so long, people are accustomed to doing whatever they feel is right to get the job done.

I am sure we have all been there before, not just with introducing structure to CSS but rather introducing new syntax rules and naming conventions. Everything is great at the start and then developers start getting lazy.

Once they start slacking off, syntax and formatting issues start arising. Pretty soon you’re using BEM and some bastardised form of it, further muddying the code-base and causing you nightmares.

Sure, in a language like Javascript or Python we can configure our IDE’s to abide by our rules. We can run linters and all of these magical tools that prevent deviations from syntax rules, but for CSS we have nothing.

To my knowledge, no syntax checker for BEM or any other CSS methodology exists. Probably because it would be impossible given the nature of how CSS works.

This is half of the problem. The other half is deciding when to apply BEM (or your chosen methodology). The problem is when someone decides to use a methodology, many do not know when to stop. Do you use it for everything, what constitutes an element having its own styling?

I have seen BEM specifically go well for some and go wrong for others. I worked on a freelance project 2 years back that used BEM. It started off well, but there was a tonne of confusion amongst the team.

Some developers got it, but most didn’t and ended up either using BEM for everything or not using it in places where they could have. Sadly most projects don’t allocate time for things like this. It is how it is.

In the end to get the project over the line, all care was thrown out the window. We left the BEM we had in, but the team was instructed to ship and get it done regardless of how they write their CSS.

I feel sorry for any developer who has had to change something since. I can only imagine coming into a code-base of conflicting styles would drive even the most sane developer mad.

Conclusion

I have no ideas or suggestions of my own to contribute to the naming problem. Introducing structure, peace, love and happiness into CSS is always going to be one of those dreams developers and managers are forever chasing.

I work with Bootstrap for its grid system from time to time. I sometimes need to add in custom styling using Bootstrap breakpoint sizes and the documentation for Bootstrap (at least version 3) is horrible.

• Extra small: xs – 480px
• Small: sm – 768px
• Medium: md – 992px
• Large: lg – 1200px

Depending on whether or not you’re working mobile first, which in that case you would be using min-width and if you’re working from a breakpoint based responsive workflow you would be using max-width instead.

Now you don’t have to go on a safari expedition to find the Bootstrap responsive sizes for your custom CSS.

As great as CSS is, there is one thing that it lacks and that is a parent selector. The supposed reason for its nonexistence is performance concerns.

People forget that the CSS specification as it currently stands offers many selector features which when used incorrectly could be considered bad for performance.

I think justifying the lack of :parent selector purely because of performance concerns is silly. It’s like Javascript lacking the native forEach method because it is less performant than a native for or while and can introduced performance issues.

Like everything else in CSS, if you’re in the camp that opposes a :parent selector, don’t ruin it for everyone else. You decide what you want to use when you’re writing CSS, not the specification.

A little use-case I encountered recently was custom styled radio elements. I have a radio input inside of a label which resembled something like this:

<label><input type="radio" name="myRadio" value="1"> My Radio</label>

In my CSS I then hid the input element and styled the label so I could have a custom styled input. However, I couldn’t use CSS and the :checked attribute because you can’t reference the parent element.

In the end I had to resort to use a DIV which contained the label and input to do the job. The point is, while I found another solution, my original solution would have been the most ideal.

Even if a parent selector were to be introduced, it isn’t like I would use it for anything other than targeting the direct parent of an element.

I would only ever need the direct parent of an element, surely that wouldn’t cause much of a performance hit? It’s the inverse of :first-child or the direct descendant selector >

Selectors Level 4

There is a little known W3C specification called Selectors Level 4 and a parent selector might exist in the spec. Another stumbling block being it will take a long time for it to be supported well enough to use any new feature.

Looking into the specification I couldn’t actually find a reference, but I found StackOverflow answers from 2014 referencing it, so perhaps they scrapped the idea? Who knows. As always, the web evolves at a snail pace (unless you’re talking about Javascript).

Polyfill/Plugin

Someone has actually created a jQuery plugin/polyfill based on ideas from the Selectors Level 4 specification which you can checkout here.

It looks like a well-designed plugin, but honestly it might be overkill if you can just work around the lack of :parent selector instead.

Conclusion

Will there be a CSS parent selector in the future, what will it look like and do we really need one? I guess time will tell.

For the moment we just have to accept the lack of a parent selector and either work around it by changing our markup or using Javascript to achieve what we want to do.

Occasionally the Internet delivers and gives us something decent other than videos of cats playing keyboards.

Flexbox is one of the newest and potentially most useful parts of CSS3 in a very long time. Support amongst browsers is fairly decent and while it is not really that new, being able to use it is.

This cheatsheet shows some nice easy to understand and follow, examples of how to use Flexbox. While the cheatsheet does not explain all of the great uses of Flexbox, it will help you understand how to use it.