Units are the web's measurement system. Abandoning fixed pixels in favor of relative units is the most important step to building modern, accessible, and fluid interfaces that adapt to any mobile device.
1Why use relative units (rem, em) in CSS?
Pixels (px) are absolute and ignore user accessibility settings. Relative units solve this:
- →rem (Root em): It is the safest unit for typography. By always being based on the root (
<html>, commonly 16px), it prevents scaling errors. - →em: It is sensitive to the parent's context. If you set
padding: 1emon a button, it will grow proportionally if that button's font size changes. Ideal for isolated modular components, but dangerous if excessively nested.
2How do Viewport units (vw, vh) and calc() work?
Environment Requirements: Modern web design requires CSS3. In environments where smartphone use predominates, mastering the viewport is critical.
- →vw & vh: Represent 1% of the physical width and height of the browser window.
100vhensures a banner occupies exactly the entire mobile screen, regardless of resolution. - →calc(): A CSS superpower. It allows mixing units. For example,
calc(100% - 50px)tells the browser to subtract fixed pixels from a dynamic percentage, solving layouts that previously required heavy JavaScript.
3Step-by-Step Breakdown
Fluid Unit Geometry. Layouts that don't scale are broken layouts. Today, we move beyond fixed pixels into the fluid world of Relative Units. This is the secret to modern responsive design and mobile-first architecture.
Root Typography: rem. The rem (root em) is the gold standard for typography and component scaling. It is strictly relative to the font-size of the root HTML element. If the user zooms their browser or has accessibility settings enabled, rem scales proportionally.
Which CSS unit is exclusively relative to the HTML root font-size, making it the mathematically safest choice to prevent uncontrolled scaling in nested elements?
- →em
- →rem
Component Scaling: em. The em unit is relative to the PARENT's font-size, not the root. It's powerful for creating isolated modular components. If you set a button's padding to 1em, the padding will automatically grow if you increase the button's text size.
While rem calculates based on the root html tag, which unit calculates its size dynamically based on the font-size of its immediate parent element?
- →em
- →px
Viewport Width: vw. Viewport Width (vw) represents exactly 1% of the physical width of the browser window. Using 100vw guarantees an element will stretch exactly across the entire screen, completely ignoring any parent container width restrictions.
If a user's mobile screen is exactly 400 pixels wide, how many physical pixels wide is an element set to 50vw?
- →50px
- →200px
Viewport Height: vh. Similarly, Viewport Height (vh) represents exactly 1% of the screen's height. Defining a Hero section as 100vh ensures it flawlessly covers the user's screen from top to bottom before they scroll, a staple of modern web design.
Which unit ensures a 'Hero' landing section occupies exactly the full height of the user's physical screen upon load?
- →vh
- →%
Arithmetic Engine: calc(). The calc() function is a CSS superpower. It acts as an arithmetic engine, allowing you to mix entirely different unit types mathematically. Need a container to be 100% wide minus a fixed 50px gap? Just calc(100% - 50px).
Which CSS function allows the rendering engine to subtract fixed absolute pixels from fluid relative percentages in real-time?
- →calc
- →math
Absolute Fallbacks: px. With all these fluid units, are pixels (px) dead? No. Pixels are 'absolute' units representing exactly one logical dot on a screen. While you should never use px for font-sizes or main layouts, they are essential for rigid micro-designs: 1px borders, precise shadows, or fixed icon dimensions.
Fluidity Secured. You have mastered CSS measurements. You can scale typography securely with rem, construct modular components with em, engineer full-bleed sections with viewport units, and calculate complex layouts with calc. Next up: Margin, Padding, and Spacing.
Set A Fixed Pixel Width. px is an absolute unit — it always renders at exactly the size you specify.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1rem-Based Sizing Is the Backbone of Respecting Browser Zoom
Every unit choice in a typographic scale ultimately determines whether a low-vision user's increased browser font-size setting actually does anything — `rem` scales with it, `px` and unitless numbers used incorrectly for font-size do not, making unit choice a direct accessibility decision, not just a styling preference.
2100vh Layouts Can Trap Content Behind Mobile Browser Chrome
A `height: 100vh` container on mobile Safari/Chrome can be partially obscured by the address bar or bottom toolbar depending on scroll state, sometimes hiding actionable buttons at the bottom of a modal or form. Use `100dvh` (dynamic viewport height) or add safe-area padding to keep critical controls reachable.
SEO Implications
- 1
calc()-Based Fluid Layouts Avoid the Overflow Bugs That Cause Layout Shift
Using `calc(100% - 250px)` to size a fluid region next to a fixed sidebar keeps totals mathematically exact across viewport sizes, preventing the horizontal-scrollbar and content-overflow bugs that commonly register as unexpected Cumulative Layout Shift.
- 2
Viewport Units Without Fallbacks Can Cause Inconsistent Mobile Rendering Across Browsers
Older mobile browser versions handle `vh` inconsistently around dynamic toolbars, occasionally causing visible content jumps as the browser chrome shows/hides; testing with `dvh`/`svh` fallbacks reduces this inconsistency, which indirectly affects mobile usability signals.
Best Practices
Use rem for Typography, % or fr for Layout Proportions, and px Only for Fixed Micro-Details
Matching each unit to its purpose — `rem` for anything that should respect user font-size preferences, `%`/`fr` for proportional layout regions, and `px` for things like 1px hairline borders — keeps a codebase both accessible and predictable, rather than reaching for one unit everywhere out of habit.
Reach for dvh Instead of vh in Any Full-Screen Mobile Layout
`100dvh` (dynamic viewport height) automatically adjusts as mobile browser toolbars show and hide, whereas static `100vh` can cause a full-screen section to be taller than the actually-visible viewport, hiding content behind browser chrome.
Frequent Bugs
A `calc(100% - 250px)` sidebar layout overflows its parent by a few pixels on some screen sizes.
Check whether the sidebar or main content also has padding or a border under the default `content-box` sizing model, which adds extra width on top of the calc() result. Apply `box-sizing: border-box` to both elements so calc() math and rendered width stay consistent.
A `100vh` hero section is taller than the visible screen on mobile, hiding its call-to-action button below the fold.
Mobile browser address bars are included inconsistently in the `100vh` calculation depending on scroll state. Switch to `100dvh` (dynamic viewport height), which recalculates as the browser's visible chrome changes.
Real-World Examples
Building a Fixed-Sidebar, Fluid-Content Layout With calc()
An admin dashboard needed a fixed 260px navigation sidebar with the main content area filling the exact remaining width, without any JavaScript measuring or resize listeners.
.sidebar { width: 260px; }
.main-content {
width: calc(100% - 260px);
box-sizing: border-box;
}