Cold Feet with CSS Units
The love/hate relation with sizing in CSS (em | rem | px | % ..)
(Units aka size measurements like px, em, rem and many more.)
This article is a first step to me publishing more of the drafts I have piled up over the past few years. Procrastination and perfectionism are keeping me from publishing and since I would like to share more of my thoughts with the world. Here you go and I hope you like this, feel free to comment and ask questions, here or on Twitter. Enjoy!
Many articles online talk about CSS units and explain them in some predefined ‘loved’ use case rather than most real life ‘hated’ cases we frequently have to deal with. This article will explain the guidelines I use in order to keep a healthy relationship with CSS units. Along with familiar units it is important to know where the newer units come in and how to create better layouts using them. Yes, layouts, I don’t want to stop atfont-size!
I will create a healthy balance in CSS between structure and consistency.
Nowadays, definitely as a JavaScript developer I feel the daily urge of getting up in the morning and getting into the new framework that got published overnight. Next to frameworks, libraries and task runners. Package managers recently also joint this trend of constantly reinventing a used concept. For better or worse and for us to find out where to commit our spare time too. When it comes to JS, we can read about this phenomenon called ‘JavaScript fatigue’. Which Dr. Axel Rauschmayer made a great article about The JavaScript fatigue fatigue.
We might overlook it, but there’s definitely a CSS Fatigue surrounding us. We just got introduced to CSS3, but we can’t always rely on all cutting edge features everywhere. We need to check sites like caniuse or quirksmode to make sure our feature will work on our targeted browsers. Finally we might need to use vendor prefixes to make sure the delivered UI represents our defined goal or just deal with the fact that we need to make trade-offs.
We easily have 99 problems in web development, even without considering CSS. So when it comes to CSS we tend to shift our confidence towards a framework like Bootstrap or Foundation to help us out. But most inconsistencies happen with the CSS units. How can we tackle this? And more important, how can we maintain a consistency in our CSS development flow?
I will use guidelines to stay loyal to CSS units.
We have our CSS units without the use of any frameworks. Because when looking at the source code of Foundation, it seems like there’s also an inconsistent usage of units. Here we see they use em for padding and rem for font-size:
When we check the accordion component, we noticerem is being used to define the padding:
This will confuse a lot of people in how it’s possible to have consistency, while using different CSS units for the same CSS property. This is intentional, I will elaborate more on this case later with a visual example. But the main point of importance here is to see that it is not easy to maintain the used units and where to start or stop in using the right CSS unit.
What about the rules of Responsive or Adaptive Web Design. First we need to understand the differences, which aren't always clear. So people use them indistinctly. Here's a great article from UXPin on what the differences are: Responsive vs Adaptive Design
I will focus on implementing CSS units in a RWD (Responsive Web Design) workflow, primarily because it has a broader implementation goal which handles most use cases in my opinion. Let’s improve the workflow and use the most suitable unit for its proper use case.
PX — The marriage with children
The one we all should know best in the digital world and have an idea on what size it represents on a screen ispixel, px or picture element. Basically the square you can see when you enlarge a regular image. The more you have to enlarge an image to see this square, the better resolution the image has. If you want to know more about images, vectors etc.. You can read my other article: A Web of Images.
Important to know is that no matter what CSS unit you are using, the browser will compute it to px in the end. That’s why px is often referred to as the ROOT UNIT. But what are the pros and cons here? If even the browser decides to use this as a final unit, shouldn’t we just use pixel and done deal?
Briefly said: No, it is static! Which can be interpreted as both a good and a bad part. The good thing is that we know 600px will always be 600px which is easily measured on a screen. But it will always be 600px, so also on a mobile device. This might distort the intended view of our component, which is something we definitely want to avoid!
We can restrict this variance of available dimensions even closer when we have a clearer view of our targeted devices. Although it would still leave us with quite some different dimensions to take into account. The static nature of our screens make it an obvious choice to represent the size in pixels. Even when we change the view mode from portrait to landscape. We can still smoothly represent the dimension size in pixels.
Images also have a certain size that can quickly be represented in pixels upon saving. We are able to scale them up or down however we intend to use them. Although it wouldn’t make sense to show items larger than the screen dimension available. Scrolling on a mobile device to fully view an image is horrible UX. When scaling images we have 2 things to consider on the specified device:
- Scaling up will cause a decrease of image quality. (desktop)
- Scaling down will cause a decrease of image loading. (mobile)
This does not mean you can’t use a more relative sizing on images in combination here. You can use em, rem, % and whatever might become available in the future. But ask yourself the question: Does it make sense to use one of these units? Of course, as everything, It depends.. Using % might make sense in some cases to set a max-width so you can fluidly transition some screens between screens. It would get quite unmaintainable if you need to switch images between every available screen dimension.
More on % later in this article! What I am trying to get at, is that you should have a certain dimension or couple in mind when you are using your images. So you don’t have bigger images than necessary and smaller images than you are trying to show. Showing a 2000px image on a device that has a dimension constraint of 440px doesn’t really make sense. If you have multiple dimensions you want to target. Then you should prepare multiple images for this.
I will plan well before I start to use any CSS unit.
If you are more interested in how to plan the use of images inside your development flow. What are the best practises on defining breakpoints and how to make sure there’s a fluent transition between multiple dimensions without the loss of scaling up/down. Then you can read my other article about this: A Web of Images.
Borders is the other element where you should use pixel. Whether it’s a shape, image or any other element you would like to set a border. When working on a screen, which has pixels. You have to make sure you can show the border properly, so the smallest border has to be at least 1px ! While you can use a more relative sizing, remember that it won’t get smaller than 1px.
I will not use anything else than at least one pixel on a border, because I know I can’t set a border on half a pixel.
Use px when you need to set some breakpoint or when you want to define constraints for a certain size in general. It’s also an easier way to go from the mockup that the designer creates to an actual development design in CSS.
EM — The complicated one
em comes as many units from the analog typography field. It is pronounced as the letter ‘m’, where it’s also derived from. It refers to the size of the letter ‘m’ of a given font. It seemed to be first as a more strict relative measure at the CSS party a while ago. The main goal was to provide an ease of work here.
Pretty soon the community realised that it wasn’t as easy as anticipated. In order to know which size an element will be. We have to know which size the parent element is or how the inheritance works, most sizes are passed by the browser as default. Which means quite a hassle to get to the perfect size as you intended from the mockup provided by the designer.
Click here to see an article with an example case of em & rem usage.
Some of you might like to calculate, but I like the browser to do that work for me. Although it is calculating the relative size from its parent, it becomes tedious to determine if you aren’t downhearted when viewing your website in different browsers. Surprise, surprise these sizes can differ cross-browser and of course cross-platform!
There you might see that you intended something around 16px, but in reality got 20px or 14px. Because the parent was already set to 12px before. You aren’t really sure of what is going to be the final size and surprises are usually not a good thing when it comes to software development.
Another good reason not to use em as a measurement is when you consider the design flow. At some point this design has to be implemented and start calculating the whole flow. I can assure you already, it’s gonna get messy!
I will not use
emon the line-height for it is like carrying water to the ocean.
Line-height is where people seem to be using em mostly nowadays. Which makes no sense, because line-heightonly needs a number (int or float). It is already relative to the font-sizeof the element it is applied to.
Bottom line:
Avoid using em unless you really have a good idea what you are doing and you have some time on your hands to plan the whole inheritance flow.
REM — The engagement
Here comes rem to save the day! As many think the ‘r’ in rem stands for relative, it actually stands for root! Primarily the biggest confusion between em and rem where em is relative to its container and rem is relative to a root base. What about this relative sizing and having a root. Why is this good and what headaches are you saved from?
Turning a quick eye to the reset css. Which unfortunately we still need to use in our web development workflow. You might notice this line: font-size: 100%
modularscale www.modularscale.com
Usually set on either the html or body element as a base. [Checking whether it is set to this or not.] Using 16px iso % just to be safe.. Apple article on best suitable font on mobile device.
We talked about the usage of frameworks like Bootstrap or Foundation. Because we rely on their knowledge of using the best practises, here we can read on their migration note in the reboot-section when changing from Bootstrap 3 to Bootstrap 4, they also move from using em to rem units on many elements, link styles, form elements: Bootstrap 4 migration note on Github.
With the engagement I focus on commitment to stability and moving on from any previous relations.
VW & VH — The divorce
These came last to the CSS party. Respectively View Width & View Height. They always represent the full width | height of the available screen size. You can see this one as you would use the position:fixed. Be careful of course, although it might seem like an easy thing to just go and override whatever..
% — The swinging one
The % is always relative to something, whether that is the screen or an element. Depending on the size of the parent element. The size will differ on the parent element.
Mostly used in a fluid layout. As everything simply works on a percentage of the screen.
font-size …
Cheat Sheet — Counseling results
An overview of what my guideline looks like:
REM:
- margin
- padding
- font-size
- width/height on small components that you want to scale relatively
px:
- when you need to have constraints
- images
- screens
- borders
%
- relative to parent…
VW || VH
- when all else fails & you need to set something to the screen size.
CH | EX — The Best Man/Woman
A short note about these new ones, although not very familiar to most and probably not shaking the CSS unit world pretty soon. The article wouldn’t be complete if I would fail to mention them.
Summary vows:
- I will create a healthy balance in CSS between structure and consistency
- I will use guidelines to stay loyal to CSS units
- I will plan well before I start to use any CSS unit.
- I will not use
emon the line-height for it is like carrying water to the ocean. - I will not use anything else than at least one pixel on a border, because I know I can’t set a border on half a pixel.
Conclusion
As with any relation, you have to put some work in it. Communication is a big help in maintaining a healthy relationship. Don’t hesitate to share your own experiences along with possible improvements to this article. You can reach out to me on Twitter for more CSS & JS counseling. If you like pictures, follow me on Instagram.
What works for me doesn’t necessarily work for you and this is a guideline, not a restriction!
Thank you for reading, leave a comment for further improvement of this and future articles!
