Forem: Taskin Mohammad Mubassir

How Viewport Units Solve CSS Problems I Used to Have

Taskin Mohammad Mubassir — Mon, 27 Oct 2025 11:35:32 +0000

The goal: fluid, predictable layouts that just work. It took me a while to get here.

The Frustration is Real

I’ve been there, staring at my screen, utterly frustrated. I wanted a simple hero section that was exactly the height of the screen. I’d set height: 100%; on everything—html, body, the div, its parent—and nothing. Or I’d try height: 100vh; and high-five myself, only to check it on my phone later and find the math was all wrong because of the stupid address bar.

For the longest time, my toolkit was px for control and % for relativity. They’re great, but they have limits. I felt like I was constantly fighting the CSS to make it do what I wanted.

Then I actually sat down to understand viewport units. And friends, it wasn't about learning new syntax. It was about finally finding the right tool to solve the layout problems that had been frustrating me for years. This is the practical guide I wish I’d had.

1. My New Toolbox: Meet vh, vw, vmin, and vmax
Let's get the basics out of the way. I think of these as the powerful, context-aware siblings of the percentage.

1vh = 1% of what I’m actually looking through—the viewport's height
1vw = 1% of the viewport's width
1vmin = 1% of the viewport's smaller dimension (so helpful on mobile!)
1vmax = 1% of the viewport's larger dimension

Here’s the lightbulb moment I had: Percentages are relative to a parent element. Viewport units are relative to the browser window itself. This was the game-changer.

2. Solving My Real Problems: Practical Use Cases
This is the good stuff. This is how I use these units to solve actual, daily layout issues.

Problem 1: "I need a dang full-screen section."
My Old Fight: The fragile chain of height: 100%; on every single parent element. It broke if you looked at it wrong.
My Viewport Solution:

.hero {
  min-height: 100vh; /* My reliable fallback */
  min-height: 100dvh; /* The modern solution that finally works (I'll explain!) */
}

Why it works: It bypasses the entire DOM tree drama. It just asks the browser: "Make this element at least as tall as the viewport." Direct. Simple. I love it.

Problem 2: "I want my spacing to feel fluid, not jumpy."
My Old Fight: A tangled mess of media queries for font-size, margin, and padding at different breakpoints. It felt so clunky.
My Viewport Solution: Fluid Everything

/* My favorite trick: fluid text that scales smoothly */
h1 {
  font-size: clamp(1.5rem, 1rem + 2vw, 2.5rem); /* No more media queries for font size! */
}

/* Margins that feel right on any screen */
.container {
  margin: 5vmin; /* Uses the smaller dimension. It just works! */
}

Why it works: It creates a truly fluid, responsive design without me having to micromanage every single breakpoint.

Problem 3: "Centering this thing is a nightmare."
My Old Fight: Negative margins, complex flexbox/grid contortions, all just to center one div.
My Viewport Solution: The Classic Trick, Finally Understood

.centered-box {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%); /* This part is the magic */
}

Why it works: I finally got it. top: 50% and left: 50% move the element's top-left corner to the center of the viewport. The transform: translate(-50%, -50%) then shifts it back by half of its own size. It’s viewport units doing the heavy lifting to find the center.

3. The Gotcha That Almost Made Me Quit (And How I Fixed It)
This is the part that, in my opinion, most articles don't talk about enough. This was my biggest "Aha!" moment.

The Problem: Mobile Browsers Hate 100vh
I built my perfect full-screen hero with min-height: 100vh;. It looked perfect on desktop. I opened it on my phone, scrolled down, the address bar hid, and the content jumped. I was devastated.

Why? Because 100vh is the height of the viewport when the address bar is visible. So when the bar hides, you have extra space you didn't account for, causing a scrollbar.

The classic 100vh problem that ruined my afternoon.
My Old (Hacky) Solution:
I’d see people using JavaScript to calculate window.innerHeight and set a CSS variable. It worked, but it felt wrong. It was a script fix for a CSS problem.

My New (Native CSS) Savior: dvh
I remember reading the spec and getting so excited. They gave us Dynamic Viewport Units.

100dvh (Dynamic Viewport Height) automatically adjusts as the browser’s UI (like the address bar) slides in and out.
It’s the tool I’d been begging for.

The Code I Use Now:

.hero {
  min-height: 100vh; /* Fallback for older browsers. They get the 'good enough' version. */
  min-height: 100dvh; /* The modern, correct, "it-just-works" way for all modern browsers. */
}

Browser Support: It’s in all the browsers I care about (Chrome, Firefox, Safari, Edge). Using it with a vh fallback is safe and responsible. This fixed my single biggest frustration with CSS layout.

4. When I Don't Reach for Viewport Units
A good craftsman knows their tools. I’ve learned when not to use these.

For Text Accessibility: I never use vw alone for font sizes. It can break browser zoom. I always pair it with clamp() and a base rem size to keep it accessible.
For Component Layouts: If I want an image to be 50% the width of its parent article, I use width: 50%;. That's a job for percentages. If I want it to be 50% of the browser window no matter where it is, I use width: 50vw;. I use the right tool for the job.

My Workflow is So Much Smoother Now
I don't see viewport units as just another thing to remember. I see them as practical problem-solvers that made my life easier.

I use dvh for full-height sections that finally work everywhere.
I use vw/vmin for fluid scaling that feels natural.
I use vmin/vmax for context-aware sizing that responds perfectly to screen orientation.

I embraced them not because they were new, but because they solved my actual problems.

What's the most creative way you've used viewport units? What problems did they solve for you? Share your stories in the comments—I’d love to learn from you!

Understanding Hoisting in JavaScript: A Simple Guide

Taskin Mohammad Mubassir — Mon, 27 Oct 2025 10:27:36 +0000

JavaScript Hoisting

🔹 What is Hoisting?
Hoisting is JavaScript's default behavior of moving declarations of functions and variables to the top of their scope before the code is executed. This means you can use a function or variable before it has been physically declared in the code. However, it's important to understand that only the declarations are hoisted, not the initializations (the assignment of a value).

In simple terms:
JavaScript scans the entire code first, remembers all variable and function declarations, and then starts running the code.
Variable Hoisting
How hoisting works with variables depends on whether you use var, let, or const.

Using var Variables declared with var are hoisted to the top of their scope and are initialized with a value of undefined. This means you can access the variable before its declaration without an error, but its value will be undefined until the assignment is made. Example: code:

console.log(myVar);         // Outputs: undefined 
var myVar = "Hello, World!"; 
console.log(myVar);         // Outputs: "Hello, World!"

How JavaScript sees it:
Code

var myVar;      // Declaration is hoisted and                          initialized as undefined          
console.log(myVar); 
myVar = "Hello, World!";    // Initialization happens here 
console.log(myVar);

Using let and const Variables declared with let and const are also hoisted, but they are not initialized with a default value. Accessing a let or const variable before it is declared will result in a ReferenceError. This is due to the Temporal Dead Zone (TDZ), which is the time from the start of the block until the variable declaration is processed. Example: Code

console.log(myLet);             // Throws ReferenceError: Cannot access                       'myLet' before initialization 
let myLet = "This will not work";

Function Hoisting

Function Declarations Function declarations are fully hoisted, meaning both the function's name and its entire logic are moved to the top. This allows you to call a function before it is declared in your code. Example: code

sayHello();             // Outputs: "Hello there!" 
function sayHello() { 
  console.log("Hello there!"); 
}

Function Expressions Function expressions, where a function is assigned to a variable, are not hoisted in the same way. If the variable is declared with the var keyword, the declaration is hoisted and initialized to undefined. Trying to call it before the assignment will result in a TypeError. If declared with let or const, it will be subject to the Temporal Dead Zone and throw a ReferenceError. Example (with var): code

sayGoodbye();       // Throws TypeError: sayGoodbye is not a function 
var sayGoodbye = function() { 
  console.log("Goodbye!"); 
};

🔹 Example Code

console.log(a);
console.log(b);
console.log(c);

let a = 10;
const b = 20;
var c = 30;

hoistingFunction();
notHostingFunction();

function hoistingFunction() {
  console.log('hi');
}
const notHostingFunction = () => {
  console.log('hello');
}

🔹 Step-by-Step Explanation
During the compilation phase, JavaScript hoists declarations:

var c;                 // Hoisted and initialized with undefined
let a;                 // Hoisted but NOT initialized (TDZ)
const b;               // Hoisted but NOT initialized (TDZ)
function hoistingFunction(){console.log('hi');} // Fully hoisted
const notHostingFunction;         // Declared but not initialized

During execution, code runs line by line:
console.log(a) → ❌ Error: Cannot access 'a' before initialization
console.log(b) → Not reached (script already stopped)
console.log(c) → Not reached

Variables with let and const are in the Temporal Dead Zone (TDZ) until their declaration line is executed.
var is accessible before initialization but holds undefined.

🔹 Function Hoisting
✅ Function Declarations

sayHi();
function sayHi() {
  console.log('Hello');
}

✅ Works perfectly because function declarations are fully hoisted (both name and body).
❌ Function Expressions / Arrow Functions

sayHello();  // Error
const sayHello = () => console.log('Hello');

🚫 Error: Cannot access 'sayHello' before initialization
Reason: Only the variable declaration (const sayHello) is hoisted, not the function value.

🔹 Variable Hoisting Summary

🔹 Temporal Dead Zone (TDZ)
The TDZ is the time between the start of the scope and the line where a let or const variable is declared.
Accessing these variables during the TDZ results in a ReferenceError.
Example:

console.log(x);  // ❌ ReferenceError
let x = 5;

🔹 Corrected Version of the Example Code

let a = 10;
const b = 20;
var c = 30;

console.log(a); // 10
console.log(b); // 20
console.log(c); // 30

hoistingFunction(); // ✅ Prints 'hi'

function hoistingFunction() {
  console.log('hi');
}


notHostingFunction(); // ❌ ReferenceError (Cannot access 'ok' before                          initialization)
const notHostingFunction = () => {
  console.log('hello');
};

🔹 Key Takeaways

Only declarations are hoisted, not initializations.
var variables are hoisted and initialized with undefined.
let and const are hoisted but remain in the Temporal Dead Zone until their line of declaration.
Function declarations are fully hoisted (can be called before they appear).
Function expressions (arrow or anonymous) behave like variables—not callable before initialization.