Pixels, bad. Percentages, good. Right? Well, I'd have to go with maybe.
Building mobile-first responsive websites and interfaces has truly become the default way of thinking for front end developers. So, actually, this line of thought does make total sense. However, I have to admit, I sometimes find myself longing for the predictability of a pixel value.
Below is an example mockup of the design scenario we are going to address. We have a comment block where a user picture needs to be aligned on the left while all other content is aligned to the right. The comment will span the entire width on smaller screens but we will align it with the title as the screen gets larger.
Small screen
Medium screen and up
When first thinking in terms of percentages, the conclusion would be that our user picture will be set to 25% wide and the rest of the content should be 75% wide. Let’s start there.
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
As we continue our responsive implementation and scale up the browser, it becomes apparent that we will have to adjust this layout for larger screens.
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
First we need to align the comment with the title.
Second, the user picture at 25% on a desktop screen is far too large. To address this, we need to define a few breakpoints and our code would now look like this.
Tablet
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
Desktop
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
While these three breakpoints look good, there are definitely some points in between where the user picture still looks disproportionate.
Mobile/Tablet
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
Tablet/Desktop
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
At this point, we would have to continue to add layout adjustments for those awkward breakpoints. Alternatively we could decide that percentages are making this task more difficult than it has to be to revert back to those predictable pixels I was telling you about.
I would prefer to avoid 100+ lines of code defining the 6 - 8 breakpoints that would make this approach work. So, let’s try something different. How can we work with pixels and still keep our layout responsive?
We can make this super simple by floating the image to the left, right? In this case, yes.
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
However, when building for data inputted by the user -- no way!
This is always a "gotcha" when building for a Content Management System (CMS) or any other scenario that accepts user generated content. Your content will never be as short and concise as your designer’s mockups suggest. In this case, the float method would cause the title and author information to wrap awkwardly when the text gets longer.
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
The beauty of the CSS calc() function is that it let’s us work with pixels and use math functions to add and subtract values from percentages. For example, we can define the width of an object like:
, .block { width: calc(100% - 100px); } ,
If our browser window was 1000px wide, this object would be 900px wide. If our browser window was 500px wide, this object would be 400px wide. The contextual awareness the calc() function has gives us another approach to try.
See the Pen RRwPxr by Leah Wagner (@leahtard) on CodePen.
That’s it. No need to define multiple breakpoints. No need to worry about extra long content entered by users. Approximately 60 lines of code that are easy to read and and understand.
What about our latest layout saviour -- Flexbox? Yes, Flexbox deserves an honourable mention here. The same solution reached with the following code:
See the Pen I heart CSS calc() by Leah Wagner (@leahtard) on CodePen.
I'm sure we can agree that both CSS calc() and Flexbox get the job done with less code. However, the project you are working on is going to dictate which the best approach is.
You will probably want to review the caniuse.com reports for CSS calc() and Flexbox to understand the impact each will have on your project.
Also, consider which option is best for you and your coworkers as you develop and maintain this project in the future.
For this example, we would most likely want to go with CSS calc(). The code is clear, easy to understand and we don’t need vendor prefixes like we would for Flexbox. It also requires less HTML markup in the form of wrapper divs when compared to the Flexbox approach.
This ultimately translates to fewer lines of code. Also, when working with Flexbox, I have a few blogs posts I always have handy as a reference. The syntax isn't second nature to me yet. In this respect, I am more efficient when taking the CSS calc() approach.
What about you? Do you heart CSS calc()?