DEV Community: Emmanuel Elikwu

HTML Can Open Dialogs Without JavaScript- Here's How command and commandfor Work

Emmanuel Elikwu — Mon, 09 Nov 2026 09:27:14 +0000

What if I told you that you could open a modal, close it, and control a popover menu using HTML alone?

No addEventListener().

No onclick handlers.

No JavaScript functions just to open and close things.

Modern HTML supports Invoker Commands, using two attributes:

commandfor
command

And they're surprisingly powerful.

In this tutorial, we'll explore them by building interactive features inside a real luxury real estate website called HAVEN Estates.

Instead of demonstrating everything with empty boxes, we'll use actual property cards, detailed property dialogs, a navigation popover, and a private-viewing form.

Prefer watching rather than reading? Watch the full step-by-step YouTube tutorial.

If you want to go deeper and build full responsive layouts faster, check out my guide: Build Any Responsive Layout with CSS Grid & Flexbox. It walks through building real pages component by component.

Let's get started.

1. The old way: JavaScript event handlers

Imagine you're building a website with a button that opens a modal.

Traditionally, you might write:

<button id="open-dialog">
  View Property
</button>

<dialog id="property-dialog">
  <h2>Villa Sereno</h2>
  <p>Explore this luxury residence.</p>
</dialog>

Then use JavaScript:

const openButton = document.querySelector("#open-dialog");
const dialog = document.querySelector("#property-dialog");

openButton.addEventListener("click", () => {
  dialog.showModal();
});

This works, and JavaScript is still essential when you need custom application logic. But for a simple built-in interaction like opening a dialog, we no longer need to write this event handler in supporting browsers.

2. Meet `commandfor` and `command`

Here's the HTML-only alternative:

<button
  type="button"
  commandfor="property-dialog"
  command="show-modal"
>
  View Property
</button>

<dialog id="property-dialog">
  <h2>Villa Sereno</h2>
  <p>Explore this luxury residence.</p>
</dialog>

That's it. The browser knows which dialog to open and what action to perform.

`commandfor` = WHERE

The commandfor attribute identifies the target element:

commandfor="property-dialog"

This connects the button to the element with the matching ID:

<dialog id="property-dialog">

Think of it as answering: Which element should this button control?

`command` = WHAT

The command attribute tells the browser what action to perform:

command="show-modal"

Think of it as answering: What should happen to that element?

The easiest way to remember the difference:

commandfor = WHERE

command = WHAT

That's the foundation of HTML Invoker Commands.

3. The commands you need to know

For built-in dialogs and popovers, common command values include:

Command	Purpose
`show-modal`	Open a dialog as a modal
`close`	Close a dialog
`request-close`	Request a dialog to close
`show-popover`	Show a popover
`hide-popover`	Hide a popover
`toggle-popover`	Toggle a popover

Some values target <dialog> elements, while others target elements with the popover attribute. That distinction is important.

Let's use them in our actual project.

4. Build a property dialog in HAVEN Estates

HAVEN Estates is a premium property website featuring luxury residential listings. Each property card contains a quick-view button.

Our goal is simple: when a visitor clicks a property button, a dialog should open with more information.

Let's use one of the properties: Villa Sereno.

Step 1: Create the button

Inside our property card, we have a button similar to this:

<button
  class="image-action"
  type="button"
  commandfor="property-sereno"
  command="show-modal"
  aria-label="Quick view of Villa Sereno"
>
  ↗
</button>

Notice three important things:

It's a real <button>.
The button points to property-sereno.
The command is show-modal.

Now we need to create the target.

Step 2: Add the dialog

<dialog
  class="modal property-dialog"
  id="property-sereno"
  aria-labelledby="dialog-title-sereno"
>
  <div class="modal-body">
    <h2 id="dialog-title-sereno">
      Villa Sereno
    </h2>

    <p>
      A luxury Mediterranean residence
      designed for exceptional coastal living.
    </p>

    <button
      type="button"
      commandfor="property-sereno"
      command="close"
    >
      Close
    </button>
  </div>
</dialog>

The id matches the button's commandfor value. That's what makes the connection work.

Click the quick-view button, and the browser opens the dialog—without a custom click handler or a JavaScript function to call showModal().

Step 3: Close the dialog

Look at our close button:

<button
  type="button"
  commandfor="property-sereno"
  command="close"
>
  Close
</button>

We target the same dialog, but change the command from show-modal to close.

What about `request-close`?

Our HAVEN project also uses this pattern for the close icon:

<button
  type="button"
  commandfor="property-sereno"
  command="request-close"
  aria-label="Close property details"
>
  ×
</button>

The difference matters:

close directly closes the dialog.
request-close requests closure through the dialog's cancelable close-request behavior.

That can be useful when an application needs to intercept a closing request, such as warning about unsaved changes. For our simple property preview, both normally result in a closed dialog.

5. Style the dialog with CSS

Native HTML controls don't mean we have to accept boring designs.

The HAVEN Estates dialogs use custom styling, property imagery, elegant typography, and a backdrop. Here's a simplified example:

.modal {
  width: min(90vw, 760px);
  max-height: 90dvh;
  padding: 0;
  border: 0;
  border-radius: 18px;
  overflow: auto;
  background: #fff;
  color: #24211d;
  box-shadow: 0 24px 80px rgba(0, 0, 0, 0.25);
}

.modal::backdrop {
  background: rgba(10, 14, 18, 0.65);
  backdrop-filter: blur(6px);
}

The ::backdrop pseudo-element styles the layer behind a modal dialog. And max-height: 90dvh limits the dialog to the dynamic viewport height, with scrolling available for longer content.

Native behavior and custom design can work together.

6. Create a navigation menu with the Popover API

Now let's move to another real feature in HAVEN Estates: the navigation button.

Clicking it reveals an additional panel containing links such as:

Discover properties
Our philosophy
Exceptional amenities
Client stories
Contact us

The panel also has a Book a private viewing button.

We can build this interaction with HTML commands and the Popover API.

Step 1: Create the trigger

<button
  class="menu-trigger"
  type="button"
  commandfor="site-menu"
  command="toggle-popover"
  aria-label="Open navigation"
>
  ☰
</button>

This time our command is toggle-popover, and the target is site-menu.

Step 2: Create the popover

<nav
  id="site-menu"
  class="site-menu"
  popover
  aria-label="Additional navigation"
>
  <div class="menu-top">
    <strong>Explore HAVEN</strong>

    <button
      type="button"
      commandfor="site-menu"
      command="hide-popover"
      aria-label="Close menu"
    >
      ×
    </button>
  </div>

  <a href="#properties">Discover properties</a>
  <a href="#story">Our philosophy</a>
  <a href="#amenities">Exceptional amenities</a>
  <a href="#testimonials">Client stories</a>
  <a href="#contact">Contact us</a>
</nav>

The important addition is the popover attribute.

Because we're using the default automatic popover behavior, the browser provides useful built-in interactions:

The command button can toggle the popover.
Escape can dismiss the open popover.
Clicking outside can dismiss it.
The open popover is placed in the top layer.

All without custom JavaScript for those behaviors.

However, a popover isn't automatically a modal dialog: it does not make the rest of the page inert or trap keyboard focus.

7. Add a viewing form without an open-modal handler

Another feature in HAVEN Estates is the private-viewing form. When a visitor clicks Schedule a viewing, a modal dialog opens.

The trigger uses the same pattern:

<button
  type="button"
  commandfor="viewing-dialog"
  command="show-modal"
>
  Schedule a viewing
</button>

And the target is:

<dialog id="viewing-dialog">
  <h2>Schedule a viewing</h2>

  <form method="dialog">
    <label for="full-name">Full name</label>
    <input id="full-name" name="name" required>

    <label for="email">Email address</label>
    <input id="email" name="email" type="email" required>

    <button type="submit">Close form preview</button>
  </form>
</dialog>

Here's another useful native HTML feature:

<form method="dialog">

When submitted through its submit button, this form can close its containing dialog rather than sending a normal network request. Do not confuse this behavior with saving a booking.

Important: In HAVEN Estates, this is only a frontend demonstration. The form does not actually send or store a viewing request. A production booking system would need server-side handling, validation, data storage, and user feedback.

8. Dialog vs. Popover: When should you use each?

Both are useful, but they solve different problems.

Feature	Modal dialog	Auto popover
Typical use	Important focused interaction	Dismissible supplementary UI
Makes background inert	Yes, when opened modally	No
Escape dismissal	Supported	Supported
Outside-click dismissal	Not automatic by default	Supported
Top-layer rendering	Yes, when modal	Yes, when shown
Example in HAVEN	Property preview, viewing form	Additional navigation

For HAVEN Estates, we use modal dialogs for detailed property previews and the viewing form, and a popover for additional navigation.

Choosing the right element improves the interaction before we even start styling it.

9. Common mistakes to avoid

Mistake 1: The IDs don't match

Incorrect:

<button commandfor="my-dialog" command="show-modal">
  Open
</button>

<dialog id="another-dialog"></dialog>

The button's target doesn't exist under that ID.

Correct:

<button commandfor="my-dialog" command="show-modal">
  Open
</button>

<dialog id="my-dialog"></dialog>

Mistake 2: Using the wrong command

These commands are not interchangeable:

command="show-modal"

is intended for a dialog, while:

command="toggle-popover"

is intended for a popover.

Mistake 3: Forgetting accessible names

A button containing only an icon can be difficult to understand without an accessible name.

Instead of:

<button commandfor="property-sereno" command="show-modal">
  ↗
</button>

Use:

<button
  commandfor="property-sereno"
  command="show-modal"
  aria-label="Quick view of Villa Sereno"
>
  ↗
</button>

Now assistive technologies can communicate its purpose.

Mistake 4: Assuming modern HTML works in every browser

Invoker Commands are modern platform features. Before using them in production, verify the browser versions your audience needs. Plan a fallback if unsupported browsers are part of your requirements.

Mistake 5: Confusing UI behavior with application functionality

Opening a booking form without JavaScript is not the same as implementing a booking system. Real business processes may still require JavaScript, a backend, authentication, persistence, and validation.

Watch the complete HAVEN Estates project

In the full video tutorial, I demonstrate:

The completed luxury real estate interface.
The starter project before commands are added.
How to connect buttons to property dialogs.
How to open and close dialogs without custom JavaScript handlers.
How to build the navigation popover.
How to control the viewing dialog.
How to test the finished interactions.

Watch the complete YouTube tutorial:

Watch the HAVEN Estates HTML Commands tutorial

Improve your responsive CSS skills

If you want to become better at building polished layouts like HAVEN Estates, check out my guide:

Build Any Responsive Layout with CSS Grid & Flexbox

Final thoughts

Modern HTML keeps getting more powerful.

The command and commandfor attributes show how browsers can handle common interface interactions without requiring custom event listeners for every button.

That doesn't mean JavaScript is obsolete. It means we can use the browser's native capabilities first and add JavaScript when our application genuinely needs it.

Have you tried HTML Invoker Commands yet?

Would you use them for dialogs and popovers in your next project?

Let me know in the comments.

Happy coding!

— CodeWithDivine

Your HTML Pages Can Animate Like This Now! (No JavaScript Required)

Emmanuel Elikwu — Thu, 22 Oct 2026 09:21:31 +0000

When navigating between HTML pages on traditional multi-page applications (MPAs), the browser reloads the page, causing an abrupt white flash or jump. For years, achieving fluid transitions meant building a Single Page Application (SPA) with React, Vue, or heavy client-side routing libraries.

That is no longer required. Modern browsers now support Native Cross-Document View Transitions, allowing smooth animations between separate, real HTML files using pure CSS.

In this tutorial, we will turn a multi-page luxury automotive site (Orion Motors) into an app-like experience with zero custom JavaScript.

1. The Core Rule: `@view-transition`

To allow separate HTML documents to participate in a cross-document view transition, both the outgoing and incoming pages must opt in.

If all your HTML pages share a single stylesheet (e.g., styles.css), you only need to write this single rule:

@view-transition {
  navigation: auto;
}

Note: This rule enables native cross-document transitions for eligible, same-origin navigations.

2. Customizing Global Page Transitions

When a view transition occurs, the browser creates temporary pseudo-elements representing the outgoing state (::view-transition-old(root)) and the incoming state (::view-transition-new(root)).

We can apply custom keyframe animations to these pseudo-elements to control our exit and entry effects:

/* Target the outgoing page */
::view-transition-old(root) {
  animation: 0.36s ease-in pageOut;
}

/* Target the incoming page */
::view-transition-new(root) {
  animation: 0.48s cubic-bezier(0.22, 1, 0.36, 1) pageIn;
}

/* Keyframe Animations */
@keyframes pageOut {
  to {
    opacity: 0;
    filter: blur(4px);
    transform: scale(0.98);
  }
}

@keyframes pageIn {
  from {
    opacity: 0;
    filter: blur(4px);
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    filter: blur(0);
    transform: translateY(0);
  }
}

3. Shared Element Transitions with `view-transition-name`

Animating whole pages is great, but modern app UI relies on shared elements—like an image on a product card morphing smoothly into the main hero image of a detail page.

To achieve this:

Give the element on Page A and the corresponding element on Page B the exact same view-transition-name.
Ensure each name is unique per rendered page.

/* Orion V12 Car Model */
.car-v12 {
  view-transition-name: orion-v12;
}

/* Orion S9 Car Model */
.car-s9 {
  view-transition-name: orion-s9;
}

/* Orion E7 Car Model */
.car-e7 {
  view-transition-name: orion-e7;
}

Refining Movement with `::view-transition-group`

You can target the container managing the named transition (::view-transition-group) to customize timing, curves, and physics:

::view-transition-group(orion-v12),
::view-transition-group(orion-s9),
::view-transition-group(orion-e7) {
  animation-duration: 0.72s;
  animation-timing-function: cubic-bezier(0.16, 1, 0.3, 1);
}

Key Takeaways

@view-transition { navigation: auto; } enables native cross-document transitions across separate same-origin HTML files.
Use ::view-transition-old(root) and ::view-transition-new(root) to customize whole-page exit and entry styles.
Assign identical view-transition-name values to elements across pages to seamlessly morph images, headings, and cards.
Keep your architecture clean, fast, and accessible without shipping heavy client-side JavaScript routers.

Take Your CSS to the Next Level 🚀

If you want to build clean, responsive layouts like a senior developer even faster, I packaged these architectural patterns into a practical resource:

👉 Grab the Guide: Build Any Responsive Layout with CSS Grid & Flexbox

It is designed to take you from layout confusion to confidently building any complex layout you see online!

Resources

🎥 Watch the Complete Step-by-Step Tutorial: YouTube Video Walkthrough

Stop Using So Many Media Queries! Use clamp() Instead!

Emmanuel Elikwu — Sat, 26 Sep 2026 09:15:40 +0000

Learn how senior frontend engineers eliminate breakpoint bloat and build fluid, production-grade UIs using native CSS math: clamp(), min(), and max().

If you open an enterprise codebase and inspect a junior developer’s stylesheet, you almost always see the same pattern:

/* ❌ The Breakpoint Trap */
@media (max-width: 1440px) { ... }
@media (max-width: 1200px) { ... }
@media (max-width: 1024px) { ... }
@media (max-width: 768px)  { ... }
@media (max-width: 480px)  { ... }

Every single breakpoint represents a threshold where typography abruptly jumps, internal component padding snaps, and elements stutter across the screen. If design updates a card width tomorrow, you have to reconcile five separate query overrides.

Senior frontend developers don't build interfaces this way. Instead of writing dozens of fragile media queries to patch every screen size, we use CSS math functions—min(), max(), and clamp()—to give the browser dynamic mathematical guardrails.

In this deep dive, we're tearing down an actual production layout—a Starbucks Holiday Showcase—and fixing 5 visual layout bugs using clean CSS math.

(Watch the full live build and visual DevTools inspection)

The Counter-Intuitive Mental Model

Before touching the code, you have to unlearn the naming convention of min() and max(). It feels completely backwards until you learn this rule:

1. `min()` Sets an Upper Ceiling

min(VALUE, CEILING) tells the browser: “Evaluate both values and pick whichever is smaller.”

/* Cap container width without writing @media (min-width: 1200px) */
.container {
  width: min(100% - 2rem, 1200px);
  margin-inline: auto;
}

On a 4K display, 1200px is smaller than 100% - 2rem, so the container caps out at 1200px. On mobile, 100% - 2rem is smaller, so it shrinks safely with a 1rem gutter. One line replaces an entire media query.

2. `max()` Sets a Lower Floor

max(VALUE, FLOOR) tells the browser: “Evaluate both values and pick whichever is larger.”

/* Ensure touch targets NEVER violate accessibility */
.btn-action {
  min-height: max(44px, 3vh);
}

The button can scale with the viewport height, but it is physically prevented from ever compressing below the 44px WCAG mobile touch-target threshold.

3. `clamp()` Creates Fluid Guardrails

clamp(MIN, PREFERRED, MAX) combines both:

$$\text{Floor (Min)} \longleftrightarrow \text{Fluid Slope (Preferred)} \longleftrightarrow \text{Ceiling (Max)}$$

The value scales dynamically along the preferred slope, but it is locked between the min and max boundaries.

The Project: Fixing 5 Layout Bugs With CSS Math

Let’s fix all 5 issues.

Bug 1: Viewport Spill & Gutter Misalignment (`.main-canvas`)

The Problem in DevTools:

The fixed navigation bar takes up 76px of height. The canvas below it had height: auto and static padding of 2.5rem 1.5rem. As a result, the total document height pushed past 100dvh, producing an unwanted vertical scrollbar on standard laptops.

The Senior Solution:

.main-canvas {
  display: grid;
  grid-template-rows: auto 1fr;
  position: relative;
  z-index: 5;
- padding: 2.5rem 1.5rem;
- height: auto;
- overflow: visible;
+ padding: 0.2rem clamp(1.2rem, 3.5vw, 3.8rem) clamp(0.6rem, 1.5vh, 1.2rem) clamp(1.2rem, 3.5vw, 3.8rem);
+ height: calc(100vh - 76px);
+ height: calc(100dvh - 76px);
+ min-height: 0;
+ overflow: hidden;
}

Why calc(100dvh - 76px)? Subtracting the exact 76px navbar height locks the canvas to the remaining viewport height.
Why dvh? On mobile browsers (Safari iOS, Chrome Android), 100vh treats the viewport as if the address bar is hidden. dvh (dynamic viewport height) adjusts when the browser bar expands or collapses.
Why min-height: 0? CSS Grid rows have a default setting of min-height: auto. This means a grid row refuses to shrink smaller than the intrinsic size of its contents. Setting min-height: 0 overrides this default and prevents overflow bugs.

Bug 2: Headline Typography Blowout (`.hero-main-title`)

The Problem in DevTools:

The headline was set to a static font-size: 3.8rem (~61px). On a 13-inch laptop, a 60px headline consumes over 180px of vertical space, pushing the product cards off the bottom of the screen.

The Senior Solution:

.hero-main-title {
- font-size: 3.8rem;
+ font-size: clamp(1.8rem, 3.2vw, 3.1rem);
  font-weight: 800;
  line-height: 1.05;
  letter-spacing: -0.03em;
  color: var(--sb-deep-forest);
}

Floor (1.8rem = ~29px): Keeps the headline bold and legible on small screens without aggressive word-wrapping.
Preferred Slope (3.2vw): At a standard 1200px laptop resolution, 3.2vw evaluates to 38.4px. The font scales continuously with every pixel change.
Ceiling (3.1rem = ~50px): Prevents the headline from blowing up on 1440p and 4K displays.

💡 Senior Pro-Tip (WCAG Accessibility): Never use pure viewport units like font-size: clamp(1.8rem, 4vw, 3.1rem). When visually impaired users zoom their browser to 200%, pure vw fails to enlarge properly, violating WCAG 1.4.4. Always ensure a stable relative base unit (rem) is mixed into your calculations for text.

Bug 3: Carousel Track Collision (`.carousel-container`)

The Problem in DevTools:

The cards were wrapped in a display: flex container. Because flex children size themselves according to their internal text strings, the inactive cards had mismatched widths, crowded the left side of the screen, and refused to align along the bottom edge.

The Senior Solution:

.carousel-container {
- display: flex;
- justify-content: flex-start;
- gap: 1rem;
- margin-top: 1.5rem;
+ display: grid;
+ grid-template-columns: 
+   minmax(230px, 265px) 
+   minmax(300px, 350px) 
+   minmax(230px, 265px) 
+   minmax(230px, 265px);
+ justify-content: center;
+ align-items: flex-end;
+ gap: clamp(1rem, 1.8vw, 2rem);
+ width: 100%;
+ height: 100%;
+ padding-top: clamp(2.8rem, 5vh, 4.2rem);
+ padding-bottom: clamp(0.4rem, 1.2vh, 1rem);
+ position: relative;
}

The minmax() Grid Strategy: The three side cards are constrained to minmax(230px, 265px). The center active card gets minmax(300px, 350px). This makes the featured card roughly 30% wider automatically.
align-items: flex-end: Anchors all four cards to the bottom baseline. Because the center card is taller (~515px vs ~410px), it extends upward, creating a stepped pedestal layout.
gap: clamp(1rem, 1.8vw, 2rem): The spacing contracts on small laptops and expands on ultra-wide screens.

Bug 4: Trapped Drink Images (`.drink-visual-box`)

The Problem in DevTools:

The Frappuccino cups had margin-top: 0, leaving them trapped inside the cards and pushing the title, dropdown selectors, and buttons into a cramped layout.

Why NOT `position: absolute`?

Taking the cup out of document flow collapses the parent card's height calculations, forcing you to hardcode static padding hacks across multiple breakpoints.

Why NOT `transform: translateY(-80px)`?

transform moves an element visually, but leaves its layout footprint behind. The space above the card remains empty, and the content below does not adjust.

The Senior Solution (Negative Margins):

/* Inactive Side Cards */
.drink-visual-box {
  width: 100%;
  display: flex;
  justify-content: center;
  align-items: center;
- margin-top: 0;
+ margin-top: -4.4rem;
  margin-bottom: 0.75rem;
  position: relative;
  z-index: 5;
}

/* Active Center Card Override */
.active-hero-card .drink-visual-box {
- margin-top: 0;
+ margin-top: -5.2rem;
  margin-bottom: 0.5rem;
  display: flex;
  align-items: center;
  justify-content: space-between;
  width: 100%;
}

A negative margin-top physically shifts the image upward in normal document flow. The card wrapper recognizes the offset, adjusting internal spacing while keeping standard stacking contexts intact.

Inactive cups (205px tall) use -4.4rem.
Active featured cup (255px tall) uses -5.2rem to account for the larger cup and whipped cream proportions.

Bug 5: Non-Accessible Action Button (`.btn-add-basket`)

The Problem in DevTools:

The "Add to Basket" button had compressed padding (0.35rem 0.6rem) and a tiny font size (0.65rem), resulting in a computed button height of only 28px.

Under WCAG 2.2 Criterion 2.5.8, mobile interactive touch targets should have a minimum target size of 44px by 44px to prevent miss-taps.

The Senior Solution:

.btn-add-basket {
  width: 100%;
  background-color: var(--white);
  color: var(--sb-dark-green);
  border: none;
  border-radius: 999px;
- padding: 0.35rem 0.6rem;
- font-size: 0.65rem;
+ padding: 0.76rem 1.2rem;
+ font-size: clamp(0.72rem, 0.8vw, 0.8rem);
  font-weight: 800;
  letter-spacing: 0.14em;
  text-transform: uppercase;
  cursor: pointer;
  box-shadow: 0 4px 14px rgba(0, 0, 0, 0.2);
  transition: var(--transition-smooth);
  margin-top: 0.2rem;
}

The Touch Target Math:

Font height: 0.8rem (~13px) $\times$ Line-height (~1.2) $\approx$ 15.6px
Vertical padding: 0.76rem top + 0.76rem bottom = 1.52rem $\approx$ 24.3px
Total button height: $15.6\text{px} + 24.3\text{px} + \text{borders} \approx \mathbf{44.5px}$

The button clears the 44px accessibility threshold across all devices without using rigid, hardcoded pixel heights.

When SHOULD You Still Use Media Queries?

Does modern CSS math mean media queries are obsolete? No.

Here is the mental model to guide your code architecture:

Use Case	Recommended Tool	Why
Sizing & Scale	`clamp()`, `min()`, `max()`	Continuous fluid scaling; eliminates layout snapping
Spacing & Gutters	`clamp()`	Keeps margins proportional from mobile to 4K
Structural Layout Shifts	`@media` / Container Queries	Converting desktop columns into a mobile swipe drawer or accordion

If you are writing a media query just to adjust font-size, padding, or gap, you are writing unnecessary CSS. Replace it with math and let the browser do what it was designed to do.

Take Your CSS to the Next Level 🚀

If you want to build clean, responsive layouts like a senior developer even faster, I packaged these architectural patterns into a practical resource:

👉 Grab the Guide: Build Any Responsive Layout with CSS Grid & Flexbox

It's designed to take you from "I don't know whether to use Grid or Flexbox" to confidently building any complex layout you see online.

Resources & Source Code:

🎥 Watch the Complete Step-by-Step Video on YouTube

How many media queries are in your current project? Drop your thoughts or questions in the comments below!

Stop Guessing CSS Positions: A Senior Dev’s Real World Guide

Emmanuel Elikwu — Tue, 22 Sep 2026 17:58:56 +0000

If you've ever typed position: absolute and watched your badge fly into the upper-left abyss of your browser window... or slapped z-index: 999999 !important; on an element only to watch it stubbornly sit behind an image card, you are not bad at CSS.

You just haven't been taught how the browser layout engine calculates coordinates and stacking contexts.

Most tutorials teach CSS positioning using isolated blue, red, and yellow boxes on a blank page. But in production, nobody pays you to position colored boxes. You build real storefronts, sticky filter bars, floating action badges, and cart drawers.

In this guide, we are breaking down all 5 CSS position values (static, relative, absolute, sticky, fixed) and z-index by fixing a real-world fashion e-commerce storefront called Chickito.

Prefer watching rather than reading? Check out the full video walk-through CLICK HERE

If you want to go deeper and build full responsive layouts faster (not just isolated patterns), I put together a complete guide Build Any Responsive Layout Faster with Grid and Flexbox that walks through building real pages component by component. Worth a look if this post is useful to you.

The 5 Values & Their Coordinate Offsets

Before fixing the layout, let's establish the fundamental rule:

position: static | relative | absolute | fixed | sticky;

When an element is positioned with any value other than static, you unlock five coordinate properties:

top
bottom
left
right
z-index

Let's explore how each one works in production.

1. `position: static` (The Document Flow)

The Problem: Look at our shopping cart button in the navbar. We have an icon button, and right next to it, a <span> badge with the number 2. In our starter code, the badge is pushing the navbar down awkwardly:

<div class="cart-btn-wrapper">
  <button class="nav-action-btn"><i class="ph-bold ph-shopping-bag"></i></button>
  <span class="cart-badge-count">2</span>
</div>

If you try to move this badge using offsets:

.cart-badge-count {
  top: -10px;
  right: -5px;
  z-index: 100;
}

Nothing moves. Why?

Senior Dev Rule #1: Every HTML element is position: static by default. Static elements live strictly inside the Normal Document Flow. Block elements stack, inline elements sit side-by-side, and the browser completely ignores top, bottom, left, right, and z-index.

To move this badge, we have to step outside of the static flow.

2. `position: relative` (The Coordinate Anchor)

If you change the badge to position: relative:

.cart-badge-count {
  position: relative;
  top: -10px;
}

It shifts upward, but look at where it used to be: it leaves behind an empty ghost footprint.

An element with position: relative remains in the normal document flow. The browser reserves its original physical space and only shifts the rendered pixels visually.

Senior Dev Rule #2: Never use position: relative with top/left to nudge layout. It leaves phantom gaps. Instead, relative has one primary superpower: acting as a zero-movement coordinate anchor for absolute children.

Instead of nudging the badge, we make its parent wrapper relative with zero offsets:

.cart-btn-wrapper {
  position: relative; /* Coordinate anchor */
  display: inline-flex;
}

The parent doesn't move a single pixel, but it establishes a boundary for its descendants.

3. `position: absolute` (Badges, Overlays & Mathematical Centering)

Now we target the badge child:

.cart-badge-count {
  position: absolute;
  top: -6px;
  right: -8px;
}

The instant you declare position: absolute:

The element is ripped out of the document flow. It takes up zero physical space. Adjacent elements snap together as if it doesn't exist.
It looks up the DOM tree for the nearest ancestor with a position other than static.

Because .cart-btn-wrapper is position: relative, the badge anchors directly to the top-right corner of the shopping bag.

What happens if you forget position: relative on the parent?

The badge searches up the DOM tree, finds nothing, and anchors to the viewport. That's why badges randomly fly into the top-left corner of the browser window.

Production Pattern: Mathematical Centering

In our hero section, we have a decorative circular backdrop behind the fashion model. How do you center an absolute element dead-center inside its parent?

.hero-visuals {
  position: relative; /* The Anchor */
}

.circle-backdrop {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

top: 50% and left: 50% place the top-left corner of the circle at the parent's center.
transform: translate(-50%, -50%) shifts the element backward by half its own width and height.

4. `position: sticky` & The Fatal Overflow Bug

When users scroll through a catalog of outfits, we want our category filter bar (All, Dresses, T-shirts) to follow them, but only while they are browsing:

.sticky-filter-wrapper {
  position: sticky;
  top: 0;
  backdrop-filter: blur(10px);
}

position: sticky is a hybrid: it behaves like position: relative until you scroll past a defined threshold, at which point it locks like position: fixed within its parent container.

The Two Non-Negotiable Rules of Sticky:

You must define an offset threshold (top: 0;). Without it, the browser doesn't know where to stick, and fails silently.
The overflow: hidden Trap: If any ancestor container has overflow: hidden, overflow: scroll, or overflow: auto, sticky breaks completely. The browser loses the scroll coordinate context.

5. Stopping Stacking Wars: `z-index` & Stacking Contexts

As we scroll past our product cards, a common bug occurs: the red "Hot" and "New" badges on Card 2 slice right over our sticky category icons!

Junior developers immediately reach for this hack:

/* THE ANTI-PATTERN */
.sticky-filter-wrapper {
  z-index: 999999 !important;
}

Never do this. It creates an unmaintainable "arms race" across your team.

Why z-index: 999999 fails:

z-index is not global. It is scoped to its local Stacking Context.

Think of stacking contexts like folders on your computer:

Folder 1: Card A (z-index: 1)
Folder 2: Card B (z-index: 2)

Even if a badge inside Folder 1 has z-index: 999999, it is still trapped inside Folder 1. And Folder 2 always paints over Folder 1.

The Senior Solution: Design Tokens in `:root`

Create an explicit, semantic layer hierarchy:

:root {
  --z-base: 1;              /* Background spheres & graphics */
  --z-card-badge: 10;       /* Product card tags */
  --z-sticky-nav: 50;       /* Category filter bars */
  --z-fixed-floating: 100;  /* Global chat & modals */
}

/* Assign with zero guesswork: */
.circle-backdrop { z-index: var(--z-base); }
.badge-stack { z-index: var(--z-card-badge); }
.sticky-filter-wrapper { z-index: var(--z-sticky-nav); }

Now, the sticky nav (50) cleanly paints over product badges (10) without any arbitrary numbers.

6. `position: fixed` & Mobile FAB Adaptation

At the very bottom of our storefront sits our "Chat with Stylist" support button:

.fixed-support-btn {
  position: fixed;
  bottom: 24px;
  right: 24px;
  z-index: var(--z-fixed-floating);
}

Unlike absolute (which binds to the nearest positioned ancestor), fixed rips the element out of flow and pins it directly to the viewport. No matter where the user scrolls, it stays glued to the bottom-right corner.

Mobile Responsive Polish

On small screens, a wide pill button blocks product cards. With a simple media query, we can morph it into a circular Floating Action Button (FAB):

@media (max-width: 640px) {
  .fixed-support-btn span {
    display: none; /* Hide the label */
  }

  .fixed-support-btn {
    width: 52px;
    height: 52px;
    padding: 0;
    justify-content: center;
    border-radius: 50%;
    bottom: 18px;
    right: 18px;
  }
}

Summary: The Senior Dev Mental Model

Value	Document Flow	Coordinate Context	Primary Use Case
`static`	In Flow	None (offsets ignored)	Default layout flow
`relative`	In Flow (ghost space)	Itself	Coordinate anchor for child elements
`absolute`	Ripped Out	Nearest positioned ancestor	Badges, tooltips, overlays
`sticky`	Hybrid	Parent container + scroll threshold	Section filter bars, sticky table headers
`fixed`	Ripped Out	Browser Viewport	Floating chat, back-to-top buttons

Over to You

What is the single most frustrating CSS positioning bug you've ever had to debug in production? Drop your horror story in the comments below! 👇

How to Build an Asymmetric Bento Grid Layout Like a Senior Developer With CSS Grid & Flexbox

Emmanuel Elikwu — Fri, 18 Sep 2026 06:43:40 +0000

If you've ever looked at a site like Apple, Stripe, or a modern SaaS landing page and wondered how they get boxes of different sizes to line up so perfectly, that's a bento grid layout, and it's the #4 CSS layout every developer needs in their toolkit.

In this tutorial, I'll break down exactly how to build one from scratch using nothing but CSS Grid and Flexbox, no frameworks, no libraries, by recreating a real furniture e-commerce UI called WOOLEN, component by component.

📺 Prefer to watch instead? Full step-by-step build here

What You'll Learn

The one CSS Grid rule that creates asymmetric ("bento") layouts
When to reach for Grid vs. Flexbox (and why you usually need both)
Nested CSS Grid for complex, multi-section UIs
Glassmorphism styling with backdrop-filter
Fully responsive design — without rewriting your HTML

The Core Rule: Grid for Skeleton, Flexbox for Content

Before touching any code, remember this rule, it will save you from 90% of layout confusion:

Use CSS Grid for the big two-dimensional skeleton (rows AND columns). Use Flexbox for the one-dimensional content living inside each grid cell.

If you want to go deeper and build full responsive pages faster (not just isolated patterns), I put together a complete guide Build Any Responsive Layout Faster with Grid and Flexbox that walks through building real pages component by component. Worth a look if this post is useful to you.

Step 1: The Asymmetric Grid Ratio (the actual "bento" secret)

The entire asymmetric look comes down to one line:

\css .main-bento-grid { display: grid; grid-template-columns: 1fr 1.65fr; gap: 14px; } \\

fr is a Grid-only unit meaning "a fraction of remaining space." 1fr 1.65fr splits the row into 2.65 shares total, column 1 gets 1 share (~38%), column 2 gets 1.65 shares (~62%). No manual percentage math, and it stays proportional at every screen size.

That's it. That single line is the difference between a boring equal-column layout and a genuine bento layout.

Step 2: Nesting Grids Inside Grid Cells

Real bento layouts aren't one giant grid, they're small grids nested inside grid cells, as deep as the design needs:

\css .right-bento-column { display: grid; grid-template-rows: auto 1fr; gap: 14px; } \\

This lets the promo row stay compact (auto) while the popular-items section stretches (1fr) to match the hero card's height.

Step 3: Flexbox Handles Everything Inside

Once the skeleton exists, every piece of content alignment, header items, button icon+label pairs, card headers, is a simple Flexbox row or column:

\css .site-header { display: flex; align-items: center; justify-content: space-between; gap: 16px; } \\

Step 4: Equal Columns with `repeat()`

For evenly-sized card grids (like a 3-up product row), skip typing 1fr three times:

\css .popular-cards-grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 12px; } \\

Step 5: Responsiveness — No HTML Changes Required

The most important lesson for responsive Grid layouts: you don't need different markup for mobile, you just redeclare grid-template-columns inside a media query:

\css @media (max-width: 767px) { .main-bento-grid { grid-template-columns: 1fr; } } \\

Every child automatically re-flows into a single column — the entire "make it responsive" move for the whole layout.

Recap

CSS Grid builds every skeleton, the outer bento grid, the nested right column, the product/footer grids.
Flexbox handles every piece of content alignment inside those grid cells.
Asymmetry comes from feeding Grid unequal fr ratios instead of equal ones.
Responsiveness is just re-declaring grid-template-columns inside media queries.

Watch the full build (with live coding + explanations) here 👇

{https://youtu.be/OzxmaUChWLM}

If you want to master responsive layouts faster, check out my guide "Build Any Responsive Layout with CSS Grid & Flexbox"

link to my YouTube channel

Follow me here on DEV and subscribe on YouTube for the rest of this CSS layouts series 🚀

I Cloned Instagram's full UI The Two Column Layout (Built With CSS Grid + Flexbox)

Emmanuel Elikwu — Tue, 15 Sep 2026 20:20:07 +0000

A junior dev on my team once spent two days rebuilding the same sidebar layout three separate times, one version for desktop, one for tablet, one for mobile. Three different CSS files. Three different approaches.

When I asked why, he said: "The layouts are just... different."

They weren't. He just hadn't seen the pattern yet.

That sidebar-plus-content layout he kept rebuilding from scratch? It's the exact same structural pattern behind Gmail, Notion, Slack, YouTube Studio, and pretty much every SaaS dashboard you've ever used. One fixed-width column. One fluid column. CSS Grid for the split, Flexbox for everything living inside it. Once that clicks, you stop rebuilding it every time a design brief looks slightly different, you just recognize it.

That's the idea behind my latest full-length tutorial. I clone Instagram's complete desktop-and-mobile UI from scratch using nothing but HTML, CSS, and vanilla JavaScript, but Instagram is really just the excuse. The actual goal is teaching the two-column app-shell layout as a reusable pattern, not a one-off clone.

Quick,before we go further: if you want to build layouts like this one fast, without the trial and error most developers go through, I put together a companion guide for exactly that, Build Any Responsive Layout with CSS Grid & Flexbox. It's 150+ pages, 100+ real examples, and it's built around the same Grid-vs-Flexbox decision framework this article walks through, so you're laying out pages like a pro instead of guessing and re-guessing grid-template-columns for twenty minutes. Worth keeping open in a tab while you build. GRAB IT HERE

Why this layout shows up everywhere

Almost every "app shell" on the web breaks down into the same two regions:

+---------------+-----------------------------+
|               |                              |
|   NAVIGATION  |        MAIN CONTENT          |
|  (fixed-ish   |       (fluid, scrolls,       |
|    width)     |        holds everything      |
|               |        else)                 |
+---------------+-----------------------------+

A fixed or semi-fixed navigation rail, and a fluid content area that eats up whatever space is left. That's it. That's the whole pattern, and it's worth internalizing because it removes an entire category of "how do I structure this page" decision-fatigue from your future projects.

The rule that actually matters: Grid vs. Flexbox

Here's the mental model I build the whole tutorial around:

CSS Grid is for page-level regions. Flexbox is for content-level rows and columns.

You reach for Grid when you're dividing the page into zones. You reach for Flexbox when you're arranging things inside one of those zones. They're not competing tools, they operate at different scales of the same layout, and you'll switch between them constantly, sometimes nesting one inside the other.

The outer shell itself is just two lines of actual layout logic:

.app-container {
  display: grid;
  grid-template-columns: 280px 1fr;
  min-height: 100vh;
}

280px is a fixed track — it never moves. 1fr is a fractional track — it means "take up everything that's left over." That combination, fixed-plus-fluid, is the layout decision doing all the work.

What the full tutorial covers

The video walks through the entire build, component by component, including:

The exact decision framework for choosing Grid vs. Flexbox (no more guessing)
Building a sidebar that stays pinned in place with position: sticky while the main content scrolls independently underneath it
A three-line CSS trick for perfectly responsive square image grids, no JavaScript, no fixed pixel dimensions
Turning one desktop layout into a working mobile layout using media queries that toggle pre-built regions, instead of rebuilding the page from scratch
The gradient-text trick, hover choreography, and a handful of other small details that separate "it works" from "it looks designed"
Wiring the whole thing up with vanilla JavaScript, event delegation, DOM traversal, and a fully working create-post/like/comment/share flow

Every section is built live, explained as it's written, so you can follow along and actually type it out yourself rather than just watching a finished result scroll by.

Watch the full build

The complete tutorial is on my channel, Code With Divine, link at the top of this post. If you're a frontend developer, someone leveling up from tutorials into real project structure, or just tired of rebuilding the same layout three different ways, it's worth the watch.

If a CSS pattern has ever made you rebuild something from scratch before someone showed you the "obvious" way to do it, I'd genuinely like to hear about it in the comments.

10 CSS Layouts Every Developer Should Know (Grid & Flexbox Explained the Simple Way)

Emmanuel Elikwu — Sun, 13 Sep 2026 20:12:00 +0000

You've seen these layouts a hundred times, blogs, dashboards, Pinterest boards, magazine sites. But when you sit down in front of a design file, do you know which CSS tool to reach for, or are you just guessing until something sticks?

In this post I'm breaking down 10 of the most common web layouts, and for each one I'm answering the question that actually matters: why this tool and not the other one? Once that clicks, you stop memorizing patterns and start understanding layout.

The two golden rules

Before any code, lock these in:

Flexbox is 1-directional. It arranges things in a single row, or a single column. One direction at a time.
Grid is 2-directional. Rows and columns, working together, at the same time.

That's basically the whole decision tree. Everything below is just applying it.

Quick setup

Drop this reset at the top of any project before building layouts:

*, *::before, *::after {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

body {
  font-family: system-ui, -apple-system, sans-serif;
  color: #333;
  background-color: #f8f9fa;
  line-height: 1.5;
}

Now let's build.

1. The Two-Column Layout

Sidebar for navigation, big open area for content, every SaaS dashboard and docs site ever. The ask-yourself question: am I arranging one line of things, or a whole grid of space? Sidebar and content sitting side by side is two dimensions working together, so Grid.

.two-column-layout {
  display: grid;
  grid-template-columns: 280px 1fr;
  gap: 24px;
  min-height: 100vh;
  padding: 20px;
}

1fr does the heavy lifting — "give this element whatever space is left over."

2. The Split Screen

A page cut cleanly in half — login vs. sign-up, before vs. after. Grid makes this a one-liner:

.split-screen {
  display: grid;
  grid-template-columns: 1fr 1fr;
  min-height: 100vh;
}

.pane {
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  padding: 40px;
}

Notice Grid handles the big structure, Flexbox centers the content inside each half. They're not rivals, they're teammates.

3. The Asymmetrical Layout

The one that makes beginners panic when they see it on a portfolio or SaaS landing page. It's just span:

.box-1 { grid-column: span 2; grid-row: span 2; }
.box-2, .box-3 { grid-column: span 1; }
.box-4 { grid-column: span 2; }

You're telling one box to stretch across multiple columns and rows instead of sitting in a single cell. That's how you get a big focal box with smaller boxes tucked around it.

4. The F-Shape Layout

Eye-tracking studies show users scan pages in a rough "F" across the top, down the left, across again. grid-template-areas lets you draw this layout in code:

.f-shape-container {
  display: grid;
  grid-template-areas:
    "header header"
    "sidebar main";
  grid-template-columns: 200px 1fr;
  gap: 16px;
}

It reads like an ASCII map of your page, one of the most underrated CSS features out there.

5. The Z-Shape (Zig-Zag) Layout

Image-left-text-right, then the next section flips to text-left-image-right. That alternating rhythm keeps the eye moving down a landing page. This one's Flexbox, not Grid, you're arranging a single row at a time:

.z-row {
  display: flex;
  align-items: center;
  gap: 30px;
}

.z-row.reverse {
  flex-direction: row-reverse;
}

One .reverse class, and you flip the direction instead of writing separate HTML for each section.

6. The Card Grid

Product grids, blog previews, photo galleries. The line that will change your life if you haven't used it:

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
  gap: 20px;
}

Translation: "fit as many columns as you can, each at least 250px wide, and stretch them to fill the space." That replaces an entire pile of media queries. Resize the browser and watch it reflow, no breakpoints, no JS.

7. The Featured Media Layout

One big video or image on one side, supporting text on the other, think a course platform or a watch page. Grid, but weighted:

.featured-layout {
  display: grid;
  grid-template-columns: 2fr 1fr;
  gap: 24px;
}

Grid isn't just for equal boxes — you're directing visual hierarchy with pure ratios.

8. The Masonry Layout

Pinterest. Staggered boxes of different heights. The rock-solid, widely-supported approach is CSS Multi-Column:

.masonry-layout {
  column-count: 3;
  column-gap: 16px;
}

.masonry-item {
  break-inside: avoid;
  margin-bottom: 16px;
}

Don't skip break-inside: avoid — without it, a card can get sliced in half across two columns.

9. The Magazine Layout

A big lead story, a sidebar of smaller stories, news and editorial sites live on this. Instead of span, place things by exact grid-line coordinates for full control:

.magazine-grid {
  display: grid;
  grid-template-columns: 2fr 1fr;
  grid-template-rows: auto auto;
  gap: 16px;
}

.lead-story { grid-column: 1 / 2; grid-row: 1 / 2; }
.side-stories { grid-column: 2 / 3; grid-row: 1 / 3; }

10. Fixed Navigation

The navbar that stays glued to the top while everything scrolls beneath it. Mostly Flexbox for alignment, plus one small but powerful line:

.fixed-nav {
  position: sticky;
  top: 0;
  display: flex;
  justify-content: space-between;
  align-items: center;
}

sticky isn't the same as fixed — it stays in normal document flow until you scroll past it, then locks in place. It's the behavior most devs actually want, even when they reach for fixed out of habit.

The pattern behind all 10

Don't memorize 10 layouts — internalize this:

Two things side by side that need real structure → Grid
One direction, one line of items → Flexbox
Complex named regions (header, sidebar, main) → grid-template-areas
Responsive cards with zero media queries → auto-fit + minmax()

Every layout you'll ever be handed in a design file is some combination of these ideas.

I walk through building all of these live, with a few extra interactive patterns, in the full video — check it out here:

If this was useful, drop a comment with which layout tripped you up the most, I'll dig into it in a future post.

DEV Community: Emmanuel Elikwu

HTML Can Open Dialogs Without JavaScript- Here's How command and commandfor Work

1. The old way: JavaScript event handlers

2. Meet commandfor and command

commandfor = WHERE

command = WHAT

3. The commands you need to know

4. Build a property dialog in HAVEN Estates

Step 1: Create the button

Step 2: Add the dialog

Step 3: Close the dialog

What about request-close?

5. Style the dialog with CSS

6. Create a navigation menu with the Popover API

Step 1: Create the trigger

Step 2: Create the popover

7. Add a viewing form without an open-modal handler

8. Dialog vs. Popover: When should you use each?

9. Common mistakes to avoid

Mistake 1: The IDs don't match

Mistake 2: Using the wrong command

Mistake 3: Forgetting accessible names

Mistake 4: Assuming modern HTML works in every browser

Mistake 5: Confusing UI behavior with application functionality

Watch the complete HAVEN Estates project

Improve your responsive CSS skills

Final thoughts

Your HTML Pages Can Animate Like This Now! (No JavaScript Required)

1. The Core Rule: @view-transition

2. Customizing Global Page Transitions

3. Shared Element Transitions with view-transition-name

Refining Movement with ::view-transition-group

Key Takeaways

Take Your CSS to the Next Level 🚀

Resources

Stop Using So Many Media Queries! Use clamp() Instead!

Learn how senior frontend engineers eliminate breakpoint bloat and build fluid, production-grade UIs using native CSS math: clamp(), min(), and max().

The Counter-Intuitive Mental Model

1. min() Sets an Upper Ceiling

2. max() Sets a Lower Floor

3. clamp() Creates Fluid Guardrails

The Project: Fixing 5 Layout Bugs With CSS Math

Bug 1: Viewport Spill & Gutter Misalignment (.main-canvas)

The Problem in DevTools:

The Senior Solution:

Bug 2: Headline Typography Blowout (.hero-main-title)

The Problem in DevTools:

The Senior Solution:

Bug 3: Carousel Track Collision (.carousel-container)

The Problem in DevTools:

The Senior Solution:

Bug 4: Trapped Drink Images (.drink-visual-box)

The Problem in DevTools:

Why NOT position: absolute?

Why NOT transform: translateY(-80px)?

The Senior Solution (Negative Margins):

Bug 5: Non-Accessible Action Button (.btn-add-basket)

The Problem in DevTools:

The Senior Solution:

The Touch Target Math:

When SHOULD You Still Use Media Queries?

Take Your CSS to the Next Level 🚀

Resources & Source Code:

Stop Guessing CSS Positions: A Senior Dev’s Real World Guide

The 5 Values & Their Coordinate Offsets

1. position: static (The Document Flow)

2. position: relative (The Coordinate Anchor)

3. position: absolute (Badges, Overlays & Mathematical Centering)

Production Pattern: Mathematical Centering

4. position: sticky & The Fatal Overflow Bug

5. Stopping Stacking Wars: z-index & Stacking Contexts

The Senior Solution: Design Tokens in :root

6. position: fixed & Mobile FAB Adaptation

Mobile Responsive Polish

Summary: The Senior Dev Mental Model

Over to You

How to Build an Asymmetric Bento Grid Layout Like a Senior Developer With CSS Grid & Flexbox

What You'll Learn

The Core Rule: Grid for Skeleton, Flexbox for Content

Step 1: The Asymmetric Grid Ratio (the actual "bento" secret)

2. Meet `commandfor` and `command`

`commandfor` = WHERE

`command` = WHAT

What about `request-close`?

1. The Core Rule: `@view-transition`

3. Shared Element Transitions with `view-transition-name`

Refining Movement with `::view-transition-group`

1. `min()` Sets an Upper Ceiling

2. `max()` Sets a Lower Floor

3. `clamp()` Creates Fluid Guardrails

Bug 1: Viewport Spill & Gutter Misalignment (`.main-canvas`)

Bug 2: Headline Typography Blowout (`.hero-main-title`)

Bug 3: Carousel Track Collision (`.carousel-container`)

Bug 4: Trapped Drink Images (`.drink-visual-box`)

Why NOT `position: absolute`?

Why NOT `transform: translateY(-80px)`?

Bug 5: Non-Accessible Action Button (`.btn-add-basket`)

1. `position: static` (The Document Flow)

2. `position: relative` (The Coordinate Anchor)

3. `position: absolute` (Badges, Overlays & Mathematical Centering)

4. `position: sticky` & The Fatal Overflow Bug

5. Stopping Stacking Wars: `z-index` & Stacking Contexts

The Senior Solution: Design Tokens in `:root`

6. `position: fixed` & Mobile FAB Adaptation

Step 4: Equal Columns with `repeat()`